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

[Qi Zheng]

On 1/21/26 4:20 PM, Shakeel Butt wrote:
> 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

OK, I will take a closer look.

> 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.

My mistake, please ignore it.

Thanks!