Message-ID: <CAGsJ_4wfWLbDC5SruF5TtH-VXE08OWxan12qNYSV3vGzBfe5Bg@mail.gmail.com>
Date: Thu, 17 Apr 2025 10:43:20 +0800
From: Barry Song <21cnbao@...il.com>
To: Johannes Weiner <hannes@...xchg.org>
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

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:
> > On Thu, Apr 17, 2025 at 2:18 AM Johannes Weiner <hannes@...xchg.org> wrote:
> > > Right, I'm more broadly objecting to the patch and its premise, but
> > > thought the exclusive filtering would at least mitigate its downsides
> > > somewhat. You raise good points that it's not as clear cut.
> > >
> > > IMO this is too subtle and unpredictable for everybody else. The
> > > kernel can't see the future, but access locality and recent use is a
> > > proven predictor. We generally don't discard access information,
> > > unless the user asks us to, and that's what the madvise calls are for.
> >
> > David pointed out some exceptions - the recency of dying processes might
> > still be useful to new processes, particularly in cases like:
> >
> >   while true; do app; done
> >
> > Here, 'app' is repeatedly restarted but always maintains a single running
> > instance. I agree this seems correct.
> >
> > However, we can also find many cases where a dying process means its folios
> > instantly become cold. For example:
>
> Of course, there are many of them. Just like any access could be the
> last one to that page for the next hour. But you don't know which ones
> they are. Just like you don't know if I'm shutting down firefox
> because that's enough internet for one day, or if I'm just restarting
> it to clear out the 107 tabs I've lost track off.

Typically, we focus on scenarios where multiple applications switch
seamlessly—for instance, on a phone, when transitioning between
different apps. The smoothness of these transitions matters most,
Immediately restarting a just-terminated app isn't problematic since
its memory footprint often persists before being reclaimed.

>
> > 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.

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.

While I acknowledge that counter-examples to my described pattern can always
be found, our observations clearly show that process death is a big event - far
from being just a trivial unmap operation.

Anyway, not trying to push the patch as obviously it seems quite hard :-)

Thanks
Barry

Powered by blists - more mailing lists