Now MGLRU's protection of mapped executable file folios is less reliable.
Follow the classical LRU's logic, promoting mapped executable file folios
after their first usage to give executable code a better chance to stay in
memory and improve workload performance (See patch 2 for more details).

Changes from v3:
https://lore.kernel.org/all/cover.1784268206.git.baolin.wang@linux.alibaba.com/
 - Collect tags from Johannes, Axel, Barry and Kairui. Thanks.
 - Split the helper addition out into a separate patch (per Johannes).
 - Set PG_workingset before promoting in lru_gen_set_refs() (per Kairui).
 - Some code cleanups (per Kairui).

Changes from v2:
https://lore.kernel.org/all/cover.1784197559.git.baolin.wang@linux.alibaba.com/
 - Add acked tag from David. Thanks.
 - Rename the exec-file-folio helper and move it into vmscan.c (per David).

Changes from v1:
https://lore.kernel.org/all/4b921ed528c483e13c9e22d1ae44ba58b4a15b0b.1784096432.git.baolin.wang@linux.alibaba.com/
 - Add a new patch to clean up vma flags as preparation.
 - Add a new helper to check exec file folios (per Kaisui).
 - Promote exec file folios in lru_gen_set_refs (Per Sashiko).

Baolin Wang (3):
  mm: vmscan: convert folio_referenced() to use vma_flags_t
  mm: vmscan: add a helper to identify file-backed executable folios
  mm: mglru: promote mapped executable folios after first usage

 include/linux/rmap.h |  7 +++--
 mm/rmap.c            | 19 +++++++------
 mm/vmscan.c          | 63 ++++++++++++++++++++++++++++----------------
 3 files changed, 54 insertions(+), 35 deletions(-)

-- 
2.47.3

Hi Baolin,

We backport and test an Android handset(qcom8850, 6.12, 12 GB).
Patch 1's vma_flags_t isn't on 6.12, so we kept only the core
check in its legacy form:
    (vma->vm_flags & VM_EXEC)

Since this is a backport, the numbers below just show the direction
of change. Overall the patch does well, and ran for several
hours with no crashes or hangs:

Camera (launch + capture, 22 background apps resident):
  cold-start p50        -6.3%
  capture               on par
  memavail at startup   +4 .. +7%

Reclaim over the same window, as the patch intends:
  pgsteal_kswapd -46.5%   pgscan_kswapd -52.9%
  pgsteal_direct  +0.8%   pgscan_direct  -6.7%
  pgsteal_anon  -13.8%    pgscan_anon  -13.8%
  pgsteal_file  -14.5%    pgscan_file  -30.1%

Dynamic jank (cold start + scroll, x10): missed-frame <1% on both
base and patched; not memory-bound enough to discriminate.

One trade-off, same run. PSI (memory) creeps up on the sustained
window:

                  avg10  avg60  avg300
    some base     0.00   0.03   0.33
    some patched  0.00   0.02   0.37   (+12%)
    full base     0.00   0.00   0.10
    full patched  0.00   0.00   0.13   (+30%)

and kernel stack footprint -5.3%. Reads as LMKD keeping fewer
background apps alive. This seems an Android policy interaction,
not a kernel regression. Downstreams with aggressive LMKD may
want to retune.

Just curious \ufffd\ufffd\ufffd did PSI move at all in your make -j32 run?

Best,
Zicheng