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

David Hildenbrand (Arm)
2026-04-30T15:23:18Z

On 4/29/26 23:41, Minchan Kim wrote:
> On Wed, Apr 29, 2026 at 11:09:55AM +0200, David Hildenbrand (Arm) wrote:
>> On 4/29/26 10:18, Michal Hocko wrote:
>>> [...]
>>>
>>> Page cache doesn't belong to any process.
>>>
>>> [...]
>>>
>>>
>>> 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.

Well, not in the original patch, that's what I meant :)

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

I'd assume we would want the same behavior for any form of OOM reaping.

--
Cheers,

David