Re: [PATCH v3 2/3] mm: workingset: use lruvec_page_state_local() to count lru pages

[Andrew Morton]

On Fri,  4 Sep 2026 17:45:55 +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") switched count_shadow_nodes() to lruvec_lru_size().
> With CONFIG_MEMCG enabled, lruvec_lru_size() reads mz->lru_zone_size,
> which only the classic LRU paths maintain.  MGLRU accounts its pages
> through __update_lru_size(), which skips that array, so with MGLRU on the
> four evictable LRU lists are always seen as empty.  The shadow node budget
> (pages >> 3) then collapses to slab plus unevictable pages, and the
> workingset shadow shrinker reclaims eviction tokens almost as fast as they
> are created, losing thrashing protection.
> 
> lruvec_page_state_local() reads lruvec_stats->state_local instead, which
> both classic LRU and MGLRU maintain.  Switch back to it.  The reparenting
> race this re-exposes on cgroup v2 is closed by the follow-up patch that
> redirects dying-memcg stat updates for all hierarchies.

The follow-up patch is "mm: memcg: skip the RCU lock when the memcg is
not dying"?  But that's an optimization so I'm confused.

If we're re-exposing a race, the fix for that race should have the same
Fixes: and cc:stable as the commit which did the reexposure?

It isn't clear why any of these patches is cc:stable.  The overall
effect is a tiny performance improvement?  Very clear descriptions of
end-user effects are always helpful.

So at this time I'll schedule the whole series for 7.4-rc1.  If there's
some reason why some/all of these should be backported then please lmk.