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

[T.J. Mercier]

On Thu, Oct 29, 2026 at 2:03 PM Barry Song <baohua@xxxxxxxxxx> wrote:
>
> 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's just abuse and I do not care about restart costs in that case.
I was made aware of one of the strategies apps use for this in 2022
and closed it by freezing the app cgroup before killing with:
https://cs.android.com/android/_/android/platform/frameworks/base/+/79825c6f2f8b46808e4b431fe52b3be78f1e8ac8

However there are also cases where apps are restarted by system or
vendor components after kills (quicksearchbox comes to mind) and I
don't think we'd want to zap all that memory proactively. Arguably
they shouldn't even be killed in the first place, but if they leak
that'd be a problem.

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

Yeah per-app profiling doesn't really scale to millions of apps. I
think our approach for foreground apps will probably be to use a
large-ish memory.low value that is scaled by total device memory. For
system services we're experimenting with service-specific values
closer to their actual working sets since there's a limited number of
them and we control the code. Even there I think some scaling with
device memory will still be required, since more RAM and heavier
device use mean more state for system services to manage.