Re: [PATCH v2 2/2] mm: mglru: promote mapped executable folios after first usage

[Baolin Wang]

On 7/16/26 7:10 PM, David Hildenbrand (Arm) wrote:
> On 7/16/26 12:46, Baolin Wang wrote:
> > Classical LRU protects mapped executable file folios through commit
> > 8cab4754d24a0 ("vmscan: make mapped executable pages the first class
> > citizen") and commit c909e99364c8 ("vmscan: activate executable pages
> > after first usage"), giving executable code a better chance to stay in
> > memory, avoiding IO thrashing and improving workload performance.
> >
> > However, MGLRU's protection of mapped executable file folios is less
> > reliable. Although shrink_folio_list() checks references, the access flag
> > of mapped executable file folios may have already been checked and
> > cleared by lru_gen_look_around() or walk_mm(). Additionally,
> > folio_update_gen() or lru_gen_set_refs() only sets the 'PG_referenced'
> > flag for mapped executable file folios, which causes shrink_folio_list()
> > to ignore the first usage of these mapped executable file folios and
> > reclaim them easily.
> >
> > Follow the classical LRU's logic, promoting mapped executable file folios
> > after their first usage in folio_update_gen() and lru_gen_set_refs(),
> > giving executable code a better chance to stay in memory.
> >
> > On my 32-core Arm machine, with the memcg limit set to 2G, running
> > 'make -j32' to build kernel showed some improvement in sys time.
> >
> > base			patched
> > 9248.543s		7861.579s
> >
> > Signed-off-by: Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx>
> > ---
> >   include/linux/mm_inline.h |  6 ++++++
> >   mm/vmscan.c               | 41 ++++++++++++++++++++++++---------------
> >   2 files changed, 31 insertions(+), 16 deletions(-)
> >
> > diff --git a/include/linux/mm_inline.h b/include/linux/mm_inline.h
> > index b5c4dc0f3fe3..30fdf1056312 100644
> > --- a/include/linux/mm_inline.h
> > +++ b/include/linux/mm_inline.h
> > @@ -30,6 +30,12 @@ static inline int folio_is_file_lru(const struct folio *folio)
> >   	return !folio_test_swapbacked(folio);
> >   }
> >   
> > +static inline bool folio_is_exec_file(const struct folio *folio,
> > +		const vma_flags_t *vma_flags)
> > +{
> > +	return vma_flags_test(vma_flags, VMA_EXEC_BIT) && folio_is_file_lru(folio);
> > +}
>
> I don't quite like a generic folio_is* helper to consume vma flags. Whether it
> is executable depends on the VMA. When called from a non-exec VMA it would just
> give a wrong answer.
>
> Not sure if something like "is_executable_file_folio()"/"is_exec_file_folio"
> would be better, to distinguish from the actualy folio_is* helpers that are
> independent of context.

OK. 'is_exec_file_folio' sounds better to me.

> Also, can this helper just go to vmscan.c?

Yes. I originally expected this helper might be used by other callers, 
but for now it's only used in vmscan.c, so will do.

Thanks for taking a look.