Re: [PATCH v3 2/2] mm: mglru: promote mapped executable folios after first usage
From: Baolin Wang
Date: Fri Jul 17 2026 - 09:00:34 EST
On 7/17/26 8:44 PM, Johannes Weiner wrote:
On Fri, Jul 17, 2026 at 06:05:34PM +0800, 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
While we are at it, introduce a new helper to check mapped executable
file folios.
Signed-off-by: Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx>
Both patches contained herein look good:
Acked-by: Johannes Weiner <hannes@xxxxxxxxxxx>
Acked-by: Johannes Weiner <hannes@xxxxxxxxxxx>
Thanks for reviewing.
[ Sorry ;-) Please don't mix refactoring work with functional
changes. It's difficult to look through a sequence of diff hunks
with more than one review narrative interleaved. ]
Ha, sure. Sorry for mixing in a helper replacement. I'll split it out into a separate patch next time. :)