Thread (6 messages) flat view 6 messages, 2 authors, 3d ago

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

From: Andrew Morton <akpm@linux-foundation.org>
Date: 2026-09-06 01:42:30
Also in: linux-mm, lkml, stable

On Fri,  4 Sep 2026 17:45:55 +0800 "Hui Zhu" [off-list ref] wrote:
From: Hui Zhu <redacted>

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help