Re: [RFC 0/3] mm: process_mrelease: expedited reclaim and auto-kill support

[Minchan Kim <minchan@kernel.org>]

On Thu, Apr 23, 2026 at 09:50:47AM +0200, Michal Hocko wrote:
> On Mon 20-04-26 14:53:23, Minchan Kim wrote:
> > On Fri, Apr 17, 2026 at 09:11:21AM +0200, Michal Hocko wrote:
> [...]
> > > Yes. All which make sense, really. I am still not convinced about the
> > > clean page cache because that just seems like a hack to workaround wrong
> > > userspace oom heuristics.
> > 
> > I see it a bit differently. When paltform decides to kill a process
> > to free up memory, they want that memory back right away.
> > 
> > So it doesn't make much sense for the kernel to ignore that and leave the clean
> > file pages to be picked up slowly by kswapd later.
> > 
> > In some aspects, you can think of LMKD as a more specialized, userspace version
> > of kswapd. It has high-level knowledge of process priorities and knows exactly
> > which process is safe to kill to get memory instantly. The kernel's kswapd,
> > however, operates globally without this specific process-level awareness, which
> > makes it less suited for this kind of targeted reclamation.
> > 
> > If we force LMKD to rely on the slower global kswapd to actually free the clean
> > pages, it defeats the whole purpose of targeting a specific process.
> > 
> > So letting process_mrelease speed this up isn't a hack at all. It's just helping
> > the kernel do what the admin wanted in the first place: fast, targeted memory.
> 
> This is a very creative/disruptive way to do a memory reclaim. From a
> user POV I would much rather see clean page cache reclaimed before my
> apps start to disappear. But this is obviously your call and your users
> that will care.

The problem we see in practice is that kswapd is too slow to react
to sudden memory spikes from foreground apps. By the time LMKD decides
to kill a background process to make room, the foreground app is already
stuck suffering from direct reclaim stalls, which can trigger sluggish/
jank issues which is high priority rather than sustaning background
frozen apps user didn't use recently.

> 
> Anyway, I still maintain my position. I do not think it is a good
> idea to drop clean page cache as you do not know whether there are other
> users. I am NOT NAKing this patch though but please make sure you have a
> wider support for this idea before this gets merged. Also make sure that
> all the above reasoning is part of the changelog if you want to get this
> merged.

Sure, I will make sure to include all this reasoning in the changelog of
the next version.

Thanks for review.