linux-kernel - Re: [RFC PATCH] mm: don't promote exclusive file folios of dying processes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250417121755.GB780688@cmpxchg.org>
Date: Thu, 17 Apr 2025 08:17:55 -0400
From: Johannes Weiner <hannes@...xchg.org>
To: Barry Song <21cnbao@...il.com>
Cc: David Hildenbrand <david@...hat.com>, akpm@...ux-foundation.org,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Barry Song <v-songbaohua@...o.com>,
	Baolin Wang <baolin.wang@...ux.alibaba.com>,
	Matthew Wilcox <willy@...radead.org>,
	Oscar Salvador <osalvador@...e.de>,
	Ryan Roberts <ryan.roberts@....com>, Zi Yan <ziy@...dia.com>
Subject: Re: [RFC PATCH] mm: don't promote exclusive file folios of dying
 processes

Hi Barry,

On Thu, Apr 17, 2025 at 10:43:20AM +0800, Barry Song wrote:
> On Thu, Apr 17, 2025 at 7:58 AM Johannes Weiner <hannes@...xchg.org> wrote:
> > On Thu, Apr 17, 2025 at 05:54:57AM +0800, Barry Song wrote:
> > > I agree that "access locality and recent use" is generally a good heuristic,
> > > but it must have some correlation (strong or weak) with the process lifecycle.
> >
> > I don't agree. It's a cache shared between past, present and future
> > processes. The lifecycle of an individual processes is not saying much.
> >
> > Unless you know something about userspace, and the exact data at hand,
> > that the kernel doesn't, which is why the Android usecase of MADV_COLD
> > or PAGEOUT for background apps makes sense to me, but generally tying
> > it to a process death does not.
> 
> I agree that MADV_COLD or PAGEOUT makes sense for background apps,
> but I still believe process death is somewhat underestimated by you :-) In
> Android, process death is actually a strong signal that an app is inactive and
> consuming much memory—leading to its termination by either userspace or
> the kernel's OOM mechanism.

That's exactly what I'm saying, though. You know something about
userspace that the kernel doesn't, which results from the unique way
in which app scheduling and killing works on Android. Where you have
recent foreground apps, idle background apps that you can kill and
switching back to them later transparently restarts them and shows the
user a fresh instance. But you have to admit that this is a unique
microcosm modeled on top of a conventional Unix process model.

So this doesn't necessarily translate to other Linux systems, like
servers or desktops. There is much higher concurrency, workingsets are
more static, there is no systematic distinction between foreground and
background apps (not in the Android sense), OOM killing is a rare
cornercase most setups ususally try hard to avoid etc.

But surely even Android has system management components, daemons
etc. that fit more into that second category?

> We actually took a more aggressive approach by implementing a hook to demote
> exclusive folios of dying apps, which yielded good results—reducing kswapd
> overhead, refaults, and thrashing. Of course, it is even much more controversial
> than this patch.

That doesn't sound wrong to me for Android apps.

How about a prctl() to request the behavior for those specific app
processes where you have clear usage signal? And then by all means,
outright demote the pages, or even invalidate the cache.

Delete the files, discard the flash blocks! (Ok that was a joke).