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

[Qi Zheng <qi.zheng@linux.dev>]

On 3/5/26 8:18 AM, Yosry Ahmed wrote:
> On Wed, Mar 4, 2026 at 2:03 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>>
>> On Wed, 4 Mar 2026 13:57:41 +0000 Yosry Ahmed <yosry@kernel.org> 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.