Re: [PATCH v3 28/30 fix 1/2] mm: memcontrol: fix lruvec_stats->state_local reparenting

[Shakeel Butt <shakeel.butt@linux.dev>]

On Wed, Jan 21, 2026 at 11:43:50AM +0800, Qi Zheng wrote:
> 
> 
> On 1/21/26 2:47 AM, Shakeel Butt wrote:
> > On Tue, Jan 20, 2026 at 03:19:00PM +0800, Muchun Song wrote:
> > > 
> > > 
> > > > > No reparenting local stats for v2.
> > > > 
> > > > It seems that lruvec_stats->state_local (non-hierarchical) needs to be
> > > > relocated in both v1 and v2.
> > > 
> > > Here we might need to elaborate a bit. Specifically, in the function
> > > `count_shadow_nodes`, the use of `lruvec_page_state_local` to obtain
> > > LRU and SLAB pages seems to also require these logics to work correctly.
> > > For SLAB, it appears that the statistics here have already been
> > > problematic for a while since SLAB pages have been reparented, right?
> > > 
> > 
> > Thanks a lot, now it is clear and yes it seems like SLAB is problematic
> > but now I am wondering if it is really worth fixing. For LRU pages, how
> > about using lruvec_lru_size() defined in vmscan.c. That would at least
> > keep count_shadow_nodes() working irrespective of LRU reparenting.
> 
> Do you mean calling lruvec_lru_size() in count_shadow_nodes()?

Yes but I am mainly brainstorming. We can keep the reparenting local
stats for both v1 and v2 for now as it is not a performance critical
path. I am more worried about the stats update path where upward
traversal of memcg for CSS_DYING can be costly and I don't want that in
v2.

> But
> numa_stat interface also reads lruvec_stats->state and make it visible
> to the user.
> 

Not sure how this is relevant.