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

[Qi Zheng]

On 3/5/26 8:18 AM, Yosry Ahmed wrote:
> On Wed, Mar 4, 2026 at 2:03 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> > On Wed, 4 Mar 2026 13:57:41 +0000 Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
> >
> > > > > 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).
> >
> > Yes, if the changes are reasonably small and the code has already
> > undergone significant review.
> >
> > Although the mm-new branch is quite speculative/early so I guess this
> > is less important there.
> >
> > Adding a sprinkle of -fix patches can be a pain all round, so nowadays
> > if someone sends a replacement series I'll generate and send a
> > what-you-changed-since-last-time diff.  So
> >
> > - we can check that the diff matches the changelogged updates
> > - reviewers don't have to re-review everything
> > - the author can eyeball it and think "yup, I meant to change that".
> >
> > I believe this series is due for quite a few updates so a full v6
> > resend series would be appropriate.  I'll generate the
> > how-you-changed-mm.git email from that.
>
> Thanks for chiming in. Qi, if you send a new version, I think
> separating refactoring (and moving, if needed) mod_memcg_state() and
> mod_memcg_lruvec_state() into a separate patch will make things easier
> to review.

OK, will do.