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

[Barry Song]

On Thu, Oct 29, 2026 at 5:22 AM T.J. Mercier <tjmercier@xxxxxxxxxx> wrote:
[...]
> > > > 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

Thanks! I know Minchan Kim has explored something
similar: releasing exclusive file memory when processes exit:
https://lore.kernel.org/linux-mm/20260421230239.172582-1-minchan@xxxxxxxxxx/

The idea probably wasn't well received because Android
workloads are quite different from typical server and desktop
workloads.

The fundamental assumption is that a killed app is unlikely
to be restarted shortly, so its memory is expected to lose
recency. In practice, this is usually true.

There are some exceptions, though. Some badly behaved apps
have monitors that keep restarting them whenever they are
killed. We might regress these cases by reclaiming their
memory, only for them to restart immediately and have to
read the data back from storage.

That said, this may not be common among apps on Google
Play.

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

Thanks! I guess the challenge is figuring out what value
works best for different apps. Should we collect data in the
lab, learn the appropriate value dynamically on the device,
or simply hardcode a relatively large value?

Any thoughts on this?

Best,
Barry