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

[Baolin Wang]

On 7/16/26 12:50 AM, Kairui Song wrote:
> On Wed, Jul 15, 2026 at 2:33 PM Baolin Wang
> <baolin.wang@xxxxxxxxxxxxxxxxx> wrote:
>
> Hi Baolin,
> > 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.
>
> That's really a long history for those two commits :)
> > 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() 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.
> >
> > Follow the classical LRU's logic, promoting mapped executable file folios
> > after their first usage in folio_update_gen(), giving executable code a
> > better chance to stay in memory.
>
> Yeah I think that's mostly an ideology issue, recently upstream tends
> to treat all folios fairly if there is no particular reason.
> Personally I also agree that some folios are more special compared to
> other though.

OK.

> > 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>
> > ---
> >   mm/vmscan.c | 25 +++++++++++++++----------
> >   1 file changed, 15 insertions(+), 10 deletions(-)
>
> MGLRU used to favor and put all map faulted memory at head, so could
> this be related to a recent change in any way?
> https://lore.kernel.org/linux-mm/20260526130938.66253-1-baohua@xxxxxxxxxx/

I haven't tested Barry's patch yet. Personally, I don't think this is 
closely related to Barry's patch. Though we put the faulted folios into 
the secound youngest gen before, after aging, the mapped exec folios are 
still not protected like in Classical LRU, and can be easily reclaimed.

> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index 986dde8e7429..429857852bdb 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -3188,7 +3188,7 @@ static bool positive_ctrl_err(struct ctrl_pos *sp, struct ctrl_pos *pv)
> >    ******************************************************************************/
> >
> >   /* promote pages accessed through page tables */
> > -static int folio_update_gen(struct folio *folio, int gen)
> > +static int folio_update_gen(struct vm_area_struct *vma, struct folio *folio, int gen)
> >   {
> >          unsigned long new_flags, old_flags = READ_ONCE(folio->flags.f);
> >
> > @@ -3196,10 +3196,15 @@ static int folio_update_gen(struct folio *folio, int gen)
> >
> >          /* see the comment on LRU_REFS_FLAGS */
> >          if (!folio_test_referenced(folio) && !folio_test_workingset(folio)) {
> > +               /* Activate file-backed executable folios after first usage. */
> > +               if (vma_test(vma, VMA_EXEC_BIT) && folio_is_file_lru(folio))
> > +                       goto promote;
> > +
>
> Do you think it's a good idea to extract this into a helper e.g.
> folio_is_executable_file?

Good point. Will do. Thanks.