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