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

[Yosry Ahmed]

On Wed, Mar 04, 2026 at 03:56:42PM +0800, Qi Zheng wrote:
> 
> 
> On 3/3/26 10:56 PM, Yosry Ahmed wrote:
> > On Tue, Mar 03, 2026 at 11:08:56AM +0800, Qi Zheng wrote:
> > > Hi Yosry,
> > [..]
> > > > 
> > > > I don't think we should end up with two copies of
> > > > __mod_memcg_state/mod_memcg_state() and
> > > > __mod_memcg_lruvec_state/mod_memcg_lruvec_state(). I meant to refactor
> > > > mod_memcg_state() to call __mod_memcg_state(), where the latter does
> > > > not call get_non_dying_memcg_{start/end}(). Same for
> > > > mod_memcg_lruvec_state().
> > > 
> > > Okay, like the following? But this would require modifications to
> > > [PATCH v5 31/32]. If there are no problems, I will send the updated
> > > patch to [PATCH v5 29/32] and [PATCH v5 31/32].
> > 
> > I cannot apply the diff, seems a bit corrupted.
> > 
> > But ideally, instead of a @reparent argument, we just have
> > __mod_memcg_lruvec_state() and __mod_memcg_state() do the work without
> > getting parent of dead memcgs, and then mod_memcg_lruvec_state() and
> > mod_memcg_state() just call them after get_non_dying_memcg_start().
> > 
> > What about this (untested), it should apply on top of 'mm: memcontrol:
> > eliminate the problem of dying memory cgroup for LRU folios' in mm-new,
> > so maybe it needs to be broken down across different patches:
> > 
> 
> I applied  and tested it, so the final updated patches is as follows,
> If there are no problems, I will send out the official patches.

If I am not mistaken, Andrew prefers fixups to what he already has in
mm-new (Andrew, please correct me if I am wrong).