Re: [PATCH 2/2] mm/mglru: stop rotating offlined memcgs to the old generation

[Barry Song]

On Wed, Oct 28, 2026 at 6:43 PM Kairui Song <ryncsn@xxxxxxxxx> wrote:
>
> On Tue, Oct 27, 2026 at 06:06:06PM +0800, T.J. Mercier wrote:
> > lru_gen_offline_memcg() moves an offlining memcg to the head of the old
> > generation of the memcg LRU (MEMCG_LRU_OLD), so that global reclaim
> > visits it first and evicts the folios it left behind.
> >
> > Since commit f1cf8d2f36dc ("mm: memcontrol: eliminate the problem of
> > dying memory cgroup for LRU folios"), those folios are reparented to the
> > parent before lru_gen_offline_memcg() runs, and nothing can be added
> > back to the offlined memcg's lruvec afterwards. Putting an empty
> > offlined memcg at the head of the old generation no longer serves any
> > purpose and only delays reclaim from the memcgs that still have memory
> > due to additional shrink_many() iteration.
> >
> > Remove lru_gen_offline_memcg(), so that an offlined memcg is rotated
> > like any other memcg below the reclaimable size threshold until
> > lru_gen_release_memcg() takes it off the memcg LRU. MEMCG_LRU_OLD has no
> > other user, so remove the op and update the memcg LRU comment as well.
> >
> > Signed-off-by: T.J. Mercier <tjmercier@xxxxxxxxxx>
> > ---
> >  Documentation/mm/multigen_lru.rst |  4 +---
> >  include/linux/mmzone.h            | 14 +++-----------
> >  mm/memcontrol.c                   |  1 -
> >  mm/vmscan.c                       | 20 +-------------------
> >  4 files changed, 5 insertions(+), 34 deletions(-)
> >
>
> ...
>
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index 636152d8c94d..45a2c1021f4f 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -4538,7 +4538,6 @@ bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw, unsigned int nr)
> >  enum {
> >       MEMCG_LRU_NOP,
> >       MEMCG_LRU_TAIL,
> > -     MEMCG_LRU_OLD,
> >       MEMCG_LRU_YOUNG,
> >  };
>
> I think there could be other usage of this LRU_OLD macro, but indeed
> offline is the only user currently, removing it is cleaner.

I'm imagining an Android use case where, after LMKD or similar
userspace killers implemented by various OEMs kill an application,
we may want to prioritize reclaiming its memory by making it more
likely to be scanned and reclaimed, while the killed application's
memcg still exists - not offlined.

Similarly, a foreground application might benefit from a lower
chance of being scanned and reclaimed. This suggests that Android
background-to-foreground transitions, or LMKD itself, could
potentially leverage the reordering of memcg LRUs.

But anyway, this is not a reason to keep
MEMCG_LRU_OLD for now.

>
> And everything looks good to me, thanks!
>
> Reviewed-by: Kairui Song <kasong@xxxxxxxxxxx>

+1

Reviewed-by: Barry Song <baohua@xxxxxxxxxx>