Re: [PATCH v1 2/3] mm: process_mrelease: skip LRU movement for exclusive file folios
Barry Song <[email protected]>
| Newsgroups | gmane.linux.kernel,gmane.linux.kernel.mm |
|---|---|
| Message-ID | <CAGsJ_4xn=rTM2YFhJoDopGoeSw=4PKAuKR9Nd+SjqMqxQnVaXA@mail.gmail.com> |
On Fri, Apr 24, 2026 at 3:58 PM David Hildenbrand (Arm) <[email protected]> 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 <[email protected]> > > > > 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. For some reason, while looking into Android reclaim performance, I’m re-reading Minchan’s old series. I guess the lengthy discussion you’re referring to is the one below: rfc v1: https://lore.kernel.org/linux-mm/[email protected]/ rfc v2: https://lore.kernel.org/all/[email protected]/ In v2, I added a PR_SET_FADE_ON_DEATH option so that Android can enable it while other users can leave it disabled. Maybe there’s a chance to wake it up again? > Cheers, > > David > Best Regards Barry