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

[T.J. Mercier]

On Wed, Oct 28, 2026 at 1:57 PM Barry Song <baohua@xxxxxxxxxx> wrote:
>
> 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.

I think it's an idea worth investigating. I had a similar idea which
is proactive instead of depending on reclaim hints. The code is behind
a currently inactive flag - it runs memory.reclaim on an application
cgroup before offlining it (so no zombie or reparenting), but I
haven't had time to properly test it yet.
https://cs.android.com/android/platform/superproject/+/android-latest-release:system/core/libprocessgroup/include_platform/processgroup/processgroup_platform.h;drc=2ed7b05ab42dd67391ad2819b0ee399d89128ead;l=33-34

> 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.

We are planning to use memory.low/min for foreground protection.

> 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>

Thanks!