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

[Minchan Kim <minchan@kernel.org>]

On Wed, Apr 29, 2026 at 11:09:55AM +0200, David Hildenbrand (Arm) wrote:
> 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".

After updating my development brach, I see zap_vma_for_reaping now.

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

While __oom_reap_task_mm() is indeed shared with ordinary oom_reap_task_mm(),
I added a boolean parameter (try_evict_file_folios) to isolate the
optimizations in recent patch.

-static bool __oom_reap_task_mm(struct mm_struct *mm)
+static bool __oom_reap_task_mm(struct mm_struct *mm, bool try_evict_file_folios)
 {
        struct vm_area_struct *vma;
        bool ret = true;
@@ -556,12 +556,14 @@ static bool __oom_reap_task_mm(struct mm_struct *mm)
                                                mm, vma->vm_start,
                                                vma->vm_end);
                        tlb_gather_mmu(&tlb, mm);
+                       tlb.try_evict_file_folios = try_evict_file_folios;
+                       struct zap_details details = { .ignore_access = try_evict_file_folios };
                        if (mmu_notifier_invalidate_range_start_nonblock(&range)) {
                                tlb_finish_mmu(&tlb);
                                ret = false;
                                continue;
                        }
-                       unmap_page_range(&tlb, vma, range.start, range.end, NULL);
+                       unmap_page_range(&tlb, vma, range.start, range.end, &details);
                        mmu_notifier_invalidate_range_end(&range);
                        tlb_finish_mmu(&tlb);
                }

In the current patch, ordinary oom_reap_task_mm() passes 'false', so it
does not see these side effects of broken aging and file cache eviction.

The optimizations are strictly active only when userspace calls
process_mrelease() with the PROCESS_MRELEASE_REAP_KILL flag.
(I believe OOM killer is ultimately target of the user but didn't want
to introduce side effect until we can conclude for the direction).