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

[Minchan Kim <minchan@kernel.org>]

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. This delay defeats the purpose of
"expedited" release. It’s not a global drop_caches, but rather a
targeted eviction for the victim process to make its memory immediately
available for other urgent allocations.

> 
> > Patch #2: mm: process_mrelease: skip LRU movement for exclusive file folios
> > Skips costly LRU marking (folio_mark_accessed) for exclusive file-backed
> > folios undergoing process_mrelease reclaim. Perf profiling reveals that
> > LRU movement accounts for ~55% of overhead during unmap.
> 
> OK, but why is this not desirable behavior fir mrelease?

In Android, lmkd kills background apps under memory pressure and then calls
process_mrelease. If the memory release is slow due to LRU overhead (~55% as noted),
it cannot keep up with the allocation speed of the foreground app.
This delay often leads to "over-killing" - killing more background apps
than necessary because the system hasn't yet "seen" the memory freed
from the first kill.

> 
> > Patch #3: mm: process_mrelease: introduce PROCESS_MRELEASE_REAP_KILL flag
> > Adds an auto-kill flag supporting atomic teardown. Utilizes a dedicated
> > signal code (KILL_MRELEASE) to guarantee MMF_UNSTABLE is marked in the
> > signal delivery path, preventing scheduling races.
> 
> Could you explain why those races are a real problem?

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. By combining the kill and the
release into an atomic operation with a dedicated signal code, we
guarantee that the process is reaped efficiently without competing with
the process's own teardown logic.

> -- 
> Michal Hocko
> SUSE Labs