Re: [PATCH 1/2] MAINTAINERS: MEMORY MANAGEMENT - MGLRU (MULTI-GEN LRU) update

[Barry Song]

On Wed, Nov 11, 2026 at 2:16 PM Kairui Song <ryncsn@xxxxxxxxx> wrote:
>
> On Tue, Nov 10, 2026 at 2:55 AM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Mon, 09 Nov 2026 19:31:53 +0100 "David Hildenbrand (Arm)" <david@xxxxxxxxxx> wrote:
> >
> > > MGLRU is currently the only MM component without a dedicated component
> > > maintainer. Fortunately, Kairui and Barry have been actively
> > > contributing to MGLRU and have volunteered to take on more responsibility
> > > by officially taking care of it.
> > >
> > > Given that Kairui is already an established MM component maintainer in
> > > a related MM component (SWAP), add him as an MGLRU maintainer right away.
> > >
> > > For Barry, the idea is to transition him towards a component maintainer
> > > role over the coming months, starting by moving him to the top of the
> > > reviewer list.
> > >
> >
> > Yay, thanks guys.  It's been wonderful to see the rebirth of MGLRU over
> > the past ~year.
> >
> > When do we get to remove the legacy LRU???
>
> That's on my radar :), though it will take some time and it's always
> hard to give an exact timeline...
>
> Items I'm aware of to sort out besides the FG series, maybe we can try
> to make MGLRU the default at some point during this process:
> - Refault distance, otherwise we still have a major regression in
> heavily overcommitted cases, also protects cross-memcg workingset
> thrashing. I also have an idea to remove memcg id and node id field
> from the shadow so it will have enough space to hold both the gen
> number and distance, will post that in a few weeks hopefully.
> - Memcg LRU vs. iterator (Ridong once tried to unify that, and it's
> good to see there have been optimizations for memcg LRU itself
> recently from Max).
>   I also noticed recently that the Memcg's LRU reclaim balance is
> somehow a bit broken, I'm not exactly sure why, nor a very major
> problem, I will look into it later.
> - Isolation protection (from Hui, not a very high priority, but still
> on the list, we don't want premature OOM).
> - IO cost & swappiness (Barry and I are still looking into this, with
> an series posted).
> - Page flags usage issue (FG cuts it down by 1, though it's still tight).
>
> We also have aging optimizations and async aging planned. I'm not sure
> if we are missing anything else, but we are getting close and with a
> sane todo list.

Thanks very much, Kairui. Besides the items above, I am also
thinking about a few more:

- Cross-memcg aging / look-around folio promotion (folios with
large mapcounts across multiple memcgs still easily fall back to
rmap walks today)
- mmap_lock contention during aging (perhaps switching to VMA
locks, as mmap_lock contention can cause jank in Android
foreground UI)
- Baoquan's PUD filter
- Making MGLRU more friendly to Android foreground/background
workloads

Thanks,
Barry