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

[Minchan Kim <minchan@kernel.org>]

On Thu, Apr 16, 2026 at 08:54:53AM +0200, Michal Hocko wrote:
> On Wed 15-04-26 16:26:34, Minchan Kim wrote:
> > On Wed, Apr 15, 2026 at 09:38:05AM +0200, Michal Hocko wrote:
> > > On Tue 14-04-26 13:00:16, Minchan Kim wrote:
> > > > On Tue, Apr 14, 2026 at 08:57:57AM +0200, Michal Hocko wrote:
> > > > > On Mon 13-04-26 15:39:45, Minchan Kim wrote:
> > > > > > This patch series introduces optimizations to expedite memory reclamation
> > > > > > in process_mrelease() and provides a secure, race-free "auto-kill"
> > > > > > mechanism for efficient container shutdown and OOM handling.
> > > > > > 
> > > > > > Currently, process_mrelease() unmaps pages but leaves clean file folios
> > > > > > on the LRU list, relying on standard memory reclaim to eventually free
> > > > > > them. Furthermore, requiring userspace to send a SIGKILL prior to
> > > > > > invoking process_mrelease() introduces scheduling race conditions where
> > > > > > the victim task may enter the exit path prematurely, bypassing expedited
> > > > > > reclamation hooks.
> > > > > > 
> > > > > > This series addresses these limitations in three logical steps.
> > > > > > 
> > > > > > Patch #1: mm: process_mrelease: expedite clean file folio reclaim via mmu_gather
> > > > > > Integrates clean file folio eviction directly into the low-level TLB
> > > > > > batching (mmu_gather) infrastructure. Symmetrically truncates clean file
> > > > > > folios alongside anonymous pages during the unmap loop.
> > > > > 
> > > > > Why do we need to care about clean page cache? Is this a form of
> > > > > drop_caches?
> > > > 
> > > > The goal is to ensure the memory is actually freed by the time
> > > > process_mrelease returns. Currently, process_mrelease unmaps pages, but
> > > > page caches remain on the LRU, leaving them to be reclaimed later
> > > > by kswapd or direct reclaim.
> > > 
> > > Correct. This was the initial design decision because there is not much
> > > you can assume about page cache pages which are very often shared. Even
> > > if they are not mapped by all users.
> > 
> > Fair point. However, that's the trade-off:
> > 
> > Leaving unmapped caches to be reclaimed asynchronously keeps system memory
> > pressure high for too long. In Android, this delay forces the LMKD to
> > unnecessarily kill additional innocent background apps before the memory
> > from the original victim is recovered.
> 
> OK, this is really not clear to me. How come you end up triggering LMKD
> (or any OOM handling) when there is a considerable amount of clean page
> cache?

It's not simple to explain all the heuristics, but basically, LMKD is triggered
by PSI pressure (usually contributed by kswapd rather than other components
like refault, kcompactd, or workingset operations).

It then checks the current free memory against system watermarks. Depending
on the free memory size, file cache, and free swap, it decides to start
killing background apps.

In other words, LMKD acts as a "userspace kswapd" to assist kernel kswapd's
reclamation speed. It is smarter than kswapd because it has high-level knowledge
of which processes are okay to be killed rather than forcing slow, unnecessary
paing out.

Whenever LMKD is running, kswapd is usually running alongside it. You might
wonder why LMKD kills background apps even when there are plenty of clean file
pages. That's because the system cannot predict current memory allocation rates.
If the allocation is bursty, kswapd can never catch up with the allocation speed.
This forces the foreground apps into direct reclaim, resulting in visible
UI jank. Android prioritizes UI smoothness and chooses to kill background apps.

Furthermore, when LMKD kills a background app, it expects immediate memory relief.
If the clean file pages of the killed process are left on the LRU to be reclaimed
asynchronously later, the system's memory pressure (PSI) remains high.
This forces LMKD to unnecessarily kill *additional* background apps before
the memory from the first victim is fully recovered.

Again, this is why I want process_mrelease expedite clean file reclamation
synchronously.

> 
> [...]
> 
> > > > The race occurs when the victim process starts its own exit path (after
> > > > SIGKILL) before the caller can invoke process_mrelease. If the victim
> > > > reaches the exit path first, the caller might lose the window to apply
> > > > these expedited reclamation optimizations.
> > > 
> > > Isn't this the problem you are trying to solve then? You are special
> > > casing process_mrelease while you really want to expedite the process
> > > memory clean up. 
> > > 
> > > The same situation happens with the global OOM and your approach doesn't
> > > really close the race anyway. You send SIGKILL first and the victim can
> > > hit the exit path right after that before you start processing the rest.
> > > That is not fundamentally different from doing that in two syscalls,
> > > race window is just smaller.
> > 
> > No, this approach completely close the race.
> > 
> > When it invokes do_send_sig_info(SIGKILL) with the KILL_MRELEASE code,
> > the kernel sets the MMF_UNSTABLE flag on the victim's mm_struct in the signal
> > delivery path (kernel/signal.c) *before* the task begins processing the signal.
> 
> OK, I have missed this part. I haven't really looked into specific
> patches at this stage. I am still trying to understand the motivation
> and your reasoning. So effectivelly you want to get SIGOOMKILL more or
> less.

The fundamental problem with signals is their unpredictability. The time
between sending a signal and when the victim task actually handles it is
highly non-deterministic. Furthermore, as mentioned earlier, outstanding
reference counts on the mm_struct can delay the teardown indefinitely.

> 
> > When the victim gets scheduled and wakes up to process the fatal signal,
> > the MMF_UNSTABLE flag is already set.
> > 
> > This guarantees that the victim's own exit path (do_exit -> exit_mmap) will
> > utilize the expedited reclamation optimizations automatically, regardless of
> > whether the reaper or the victim gets scheduled first.
> > 
> > For the OOM, we can use the same idea.
> > 
> > > 
> > > All that being said, I do not think those special hacks for
> > > process_mrelease is the right approach. I very much agree that the
> > > address space tear down for a dying process could be improved and we
> > > should be focusing on that part.
> > 
> > I think process_mrelease is crucial here because relying on the exit path is
> > non-deterministic.
> 
> I suspect you are missing my point. I am arguing that those special
> hacks in the address space release path shouldn't be process_mrelease

I am a bit confused now. Do you mean you want to apply these expedited
reclamation optimizations to ALL dying processes in the common exit path,
rather than making them specific to process_mrelease?

I don't think so since you mentioned below "process_mrelease might ..
right syscall" but I wanted to clarify what you means.

> specific. I do recognize the value of the sync tear down need. I am also
> in favor of something like SIGOOMKILL. process_mrelease might even be
> the right syscall for that purpose.

I am glad we are aligned on the necessity of this feature.