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

[Hui Zhu <hui.zhu@linux.dev>]

> On Tue,  8 Sep 2026 11:41:10 +0800 Hui Zhu <hui.zhu@linux.dev> wrote:
>
>> From: Hui Zhu <zhuhui@kylinos.cn>
>>
>> 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