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

[Michal Hocko]

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?

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

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