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

[Baolin Wang]

Hi Zicheng,

On 7/24/26 4:00 PM, Zicheng Wang wrote:
> 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.

Thanks for testing and sharing the performance number.

> 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.

I didn't pay attention to PSI before, but I think this is explainable.

Since we try to keep executable file folios in memory to avoid IO 
thrashing, which could cause more severe problems (such as the system 
hanging), this also means that the stall time of some other folios may 
increase. Moreover, the stall time of the original exec folios might not 
have been counted at all, for example, in filemap_read_folio(), PSI is 
only accounted for file folios marked with workingset, but before my 
patch, exec file folios might not have had a chance to set the 
workingset flag.

However, the overhead of IO thrashing is more severe than the stall time 
of other memory allocations, which is why the end-to-end performance 
improves, as seen from your data.