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

[Michal Hocko <mhocko@suse.com>]

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.

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

Clean page cache reclaim should be quite effective. Why doesn't kswapd
keep up in that regards? Or is this more a per-memcg problem where there
is no background reclaim and you are hitting direct reclaim to clean up
those pages?

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

OK, I see. More on that below.
 
> > > 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.

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.

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.
-- 
Michal Hocko
SUSE Labs