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

[Yosry Ahmed]

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.