Re: [PATCH v4 0/4] mm: workingset: fix the shadow node budget under MGLRU

[Hui Zhu]

> On Tue,  8 Sep 2026 11:41:10 +0800 Hui Zhu <hui.zhu@xxxxxxxxx> wrote:
>
> > From: Hui Zhu <zhuhui@xxxxxxxxxx>
> >
> > Commit 7404bd37cfbe ("mm: workingset: use lruvec_lru_size() to get the
> > number of lru pages") broke the workingset shadow node budget under
> > MGLRU: lruvec_lru_size() reads mz->lru_zone_size, which MGLRU never
> > maintains, so count_shadow_nodes() sees the evictable LRU lists as
> > empty and the shadow shrinker reclaims eviction tokens almost as fast
> > as they are created, losing thrashing protection.
> >
> > ...
> >
> > Performance testing
> > ===================
> >
> > The test script and the raw results are available at [1].
> >
> > Environment: 10-vCPU QEMU guest, 8 GiB RAM, cgroup v2; 7 runs per
> > configuration, medians reported.  Workloads:
> >
> >    w1-anon-churn: single-threaded anon fault/charge loop in a memcg
> >                   (MADV_DONTNEED + re-fault, no reclaim).  Every touch
> >                   is a real fault with charge and memcg stat updates,
> >                   so it stresses exactly the fast path patch 1 changes.
> >    w2-file-churn: file read loop under memory.high pressure
> >                   (reclaim-bound, noisier).
> >    w3-reparent:   reparent accounting sanity check.
> >
> > w1-anon-churn (pages/s):
> >
> >                   classic LRU          MGLRU
> > base             4393028              4377122
> > patches 1-2      4385996   (-0.2%)    4352887   (-0.6%)
> > patches 1-3      4381832   (-0.3%)    4377053   (+0.0%)
> >
> > w2-file-churn (MB/s):
> >
> >                   classic LRU          MGLRU
> > base             8277                 8226
> > patches 1-2      8226      (-0.6%)    8123      (-1.3%)
> > patches 1-3      8157      (-1.4%)    8294      (+0.8%)
> Am I misinterpreting this?  This difference is probably within
> inter-run variability?
You are reading it correctly.
The w2-file-churn differences are within run-to-run noise: it is a
reclaim-bound workload dominated by reclaim and I/O, which is too noisy
to expose the small fast-path overhead.
That is what the "within run-to-run noise" note in the cover letter
refers to.

The meaningful signal is in w1-anon-churn, which is designed to hit
exactly the fast path patch 1 changes: every iteration is a real fault
with charge and memcg stat updates, no reclaim involved.
There patches 1-2 show a consistent small overhead (-0.2%/-0.6%), and
patch 3 brings both LRU configurations back to the base level.

I can reword the cover letter in the next version to make this clearer
if you think it would help.

Best,
Hui