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

Minchan Kim
2026-04-29T21:41:48Z

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