Re: [PATCH v5 29/32] mm: memcontrol: prepare for reparenting non-hierarchical stats

[Yosry Ahmed <yosry@kernel.org>]

On Thu, Feb 26, 2026 at 9:03 AM Shakeel Butt <shakeel.butt@linux.dev> wrote:
>
> On Thu, Feb 26, 2026 at 07:16:50AM -0800, Yosry Ahmed wrote:
> > > > Did you measure the impact of making state_local atomic on the flush
> > > > path? It's a slow path but we've seen pain from it being too slow
> > > > before, because it extends the critical section of the rstat flush
> > > > lock.
> > >
> > > Qi, please measure the impact on flushing and if no impact then no need to do
> > > anything as I don't want anymore churn in this series.
> > >
> > > >
> > > > Can we keep this non-atomic and use mod_memcg_lruvec_state() here? It
> > > > will update the stat on the local counter and it will be added to
> > > > state_local in the flush path when needed. We can even force another
> > > > flush in reparent_state_local () after reparenting is completed, if we
> > > > want to avoid leaving a potentially large stat update pending, as it
> > > > can be missed by mem_cgroup_flush_stats_ratelimited().
> > > >
> > > > Same for reparent_memcg_state_local(), we can probably use mod_memcg_state()?
> > >
> > > Yosry, do you mind sending the patch you are thinking about over this series?
> >
> > Honestly, I'd rather squash it into this patch if possible. It avoids
> > churn in the history (switch to atomics and back), and is arguably
> > simpler than checking for regressions in the flush path.
>
> Yup, let's squash it into the original patch. Please add your sign-off tag.

Sure. Qi/Andrew, feel free to add these tags if you squash the diff below:

Co-developed-by: Yosry Ahmed <yosry@kernel.org>
Signed-off-by: Yosry Ahmed <yosry@kernel.org>

>
> >
> > What I have in mind is the diff below (build tested only). Qi, would
> > you be able to test this? It applies directly on this patch in mm-new:
>
> Qi, please squash this diff into the patch and test. You might need to change
> the subsequent patches. Once you are done with testing, you can post the diffs
> for those in reply to those patches and we will ask Andrew to squash into
> orinigal ones.

FWIW, after applying this diff, the rest of the series applies
cleanly. So I think we won't need diffs for other patches.

> The diff looks good to me though.

Thanks for taking a look!