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

[Minchan Kim]

On Fri, Apr 24, 2026 at 09:57:16AM +0200, David Hildenbrand (Arm) wrote:
> On 4/24/26 09:51, Michal Hocko wrote:
> > On Tue 21-04-26 16:02:38, Minchan Kim wrote:
> >> For the process_mrelease reclaim, skip LRU handling for exclusive
> >> file-backed folios since they will be freed soon so pointless
> >> to move around in the LRU.
> >>
> >> This avoids costly LRU movement which accounts for a significant portion
> >> of the time during unmap_page_range.
> >>
> >> -   91.31%     0.00%  mmap_exit_test   [kernel.kallsyms]  [.] exit_mm
> >>      exit_mm
> >>      __mmput
> >>      exit_mmap
> >>      unmap_vmas
> >>    - unmap_page_range
> >>       - 55.75% folio_mark_accessed
> >>          + 48.79% __folio_batch_add_and_move
> >>            4.23% workingset_activation
> >>       + 12.94% folio_remove_rmap_ptes
> >>       + 9.86% page_table_check_clear
> >>       + 3.34% tlb_flush_mmu
> >>         1.06% __page_table_check_pte_clear
> >>
> >> Signed-off-by: Minchan Kim <minchan@xxxxxxxxxx>
> > 
> > As pointed out in the previous version of the patch. I really dislike
> > this to be mrelease or OOM specific. Behavior. You do not explain why
> > this needs to be this way, except for the performance reasons. My main
> > question is still unanswered (and NAK before this is sorted out). Why
> > this cannot be applied in general for _any_ exiting task. As you argue
> > the memory will just likely go away so why to bother?
> 
> I think there was a lengthy discussion involving Johannes from a previous series.
> 
> That should be linked here indeed.

How about this?

    mm: process_mrelease: skip LRU movement for exclusive file folios

    During process_mrelease() or OOM reaping, unmapping file-backed folios
    spends a significant portion of CPU time in folio_mark_accessed() to
    maintain accurate LRU state (~55% of unmap time as shown in the profile
    below).

    This patch skips LRU handling for exclusive file-backed folios during
    such emergency memory reclaim.

    One might ask why this optimization shouldn't be applied to any exiting
    task in general. The reason is that for a normal, orderly exit or just
    pure kill, it is worth paying the CPU cost to preserve the active state
    of clean file folios in case they are reused soon. Preserving cache hits
    is beneficial for overall system performance.

    However, process_mrelease() and OOM reaping are emergency operations
    triggered under extreme memory pressure. In these scenarios, the highest
    priority is to recover memory as quickly as possible to avoid further
    kills or system jank. Spending half of the unmap time on LRU maintenance
    for pages belonging to a victim process is a bad trade-off. If speeding up
    the victim's reclaim by avoiding LRU movement and evicting cache negatively
    affects the workflow (due to immediate restart), it implies a sub-optimal
    kill target selection by the userspace policy (e.g., LMKD), rather than
    a problem in this expedited APIs.

    Therefore, we choose to prioritize immediate CPU savings and faster
    memory recovery over potential future cache hits for the specific victim's
    files.

    Profile showing the overhead of folio_mark_accessed during unmap:

    -   91.31%     0.00%  mmap_exit_test   [kernel.kallsyms]  [.] exit_mm
         exit_mm
         __mmput
         exit_mmap
         unmap_vmas
       - unmap_page_range
          - 55.75% folio_mark_accessed
             + 48.79% __folio_batch_add_and_move
               4.23% workingset_activation
          + 12.94% folio_remove_rmap_ptes
          + 9.86% page_table_check_clear
          + 3.34% tlb_flush_mmu
            1.06% __page_table_check_pte_clear

    Signed-off-by: Minchan Kim <minchan@xxxxxxxxxx>