Re: [PATCH v4 0/3] promote mapped executable folios after first usage for MGLRU

[Zicheng Wang <wangzicheng@honor.com>]

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 — did PSI move at all in your make -j32 run?

Best,
Zicheng