On 3/5/26 8:18 AM, Yosry Ahmed wrote:

On Wed, Mar 4, 2026 at 2:03 PM Andrew Morton [off-list ref] wrote:

quoted

On Wed, 4 Mar 2026 13:57:41 +0000 Yosry Ahmed [off-list ref] wrote:

quoted

quoted

quoted

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.