Re: [PATCH v1 2/3] mm: process_mrelease: skip LRU movement for exclusive file folios

["David Hildenbrand (Arm)" <david@kernel.org>]

On 4/29/26 10:18, Michal Hocko wrote:
> On Tue 28-04-26 18:19:31, Minchan Kim wrote:
>> On Tue, Apr 28, 2026 at 08:56:36AM +0200, Michal Hocko wrote:
> [...]
>>>         DESCRIPTION
>>>           The process_mrelease() system call is used to free the memory of
>>>           an exiting process.
>>
>> "Free the memory of an exiting process" implies all memory, not just
>> anonymous. User cannot know it will free only anonymous, and I am trying to
>> make it work as intended by completing a symmetric reclamation path.
> 
> Page cache doesn't belong to any process.
> 
> [...]
> 
>> >From cf292f8f8ead8df9161aad342c36633ffa90257f Mon Sep 17 00:00:00 2001
>> From: Minchan Kim <minchan@kernel.org>
>> Date: Tue, 28 Apr 2026 16:39:06 -0700
>> Subject: [PATCH] mm: process_mrelease: skip LRU movement and expedite clean
>>  file folio reclaim
> 
> I will let others to discuss this. I maintain my position that this is a
> hack for a very particular use case and you still seem to not explain
> non-Android users of the syscall. Anyway, I will not repeat myself here.
> 

One thing that got lost in the thread here: this code path is not
process_mrelease specific?

We seem to end up in __oom_reap_task_mm() also from ordinary oom_reap_task_mm().

There, we unconditionally set MMF_UNSTABLE to then zap_vma_for_reaping() where
memory can be "reaped".

So why is there "process_mrelease" part of the patch subject at all?


The only other scenario where we set MMF_UNSTABLE seems to be when we run into
trouble during fork(). CCing Liam, I wonder what it would take to remove
MMF_UNSTABLE from fork code now that we handle some memory freeing while
aborting fork() "more elegantly".

Unrelated stupid question: would things be clearer if we could rename
MMF_UNSTABLE to MMF_OOM_REAPING once figure out whether aborting fork() still
really needs it?


Back to Michal's original question: I guess the real question is the interaction
with memory reclaim that would just collect the access bits beforehand.

-- 
Cheers,

David