Re: [LSF/MM/BPF TOPIC] Towards Unified and Extensible Memory Reclaim (reclaim_ext)

["Lorenzo Stoakes (Oracle)" <ljs@kernel.org>]

On Thu, Mar 26, 2026 at 02:42:35PM +0100, David Hildenbrand (Arm) wrote:
> On 3/26/26 14:13, Lorenzo Stoakes (Oracle) wrote:
> > On Thu, Mar 26, 2026 at 08:37:06PM +0800, Kairui Song wrote:
> >> On Thu, Mar 26, 2026 at 4:02 PM Lorenzo Stoakes (Oracle) <ljs@kernel.org> wrote:
> >>>
> >>>
> >>> I'm quite concerned about maintainership, as it seems the MGLRU maintainers have
> >>> not been all that active, and the MGLRU to me at least is currently a black box.
> >>>
> >>> I'm not the only one who's raised this (see [0]).
> >>>
> >>> That'd very much have to be resolved and the community reassured that MGLRU is
> >>> _actively_ maintained before we could even contemplate it replacing the
> >>> 'classic' reclaim approach IMO.
> >>>
> >>> I hope that Kairu, Barry, Zicheng and others who are interested int it resolve
> >>> this, however!
> >>
> >> Hi everyone,
> >>
> >> Right, I think we are starting to make good progress on improving
> >> MGLRU recently. For the last few years we already have some commits
> >> stashed downstream to enable that on our fleet, most of my effort in
> >> upstream is spent on other parts like SWAP, really looking forward to
> >> making MGLRU better upstreamly.
> >>
> >> Yesterday I was still discussing with CachyOS folks about their usage
> >> while working on that series for MGLRU cleanup and dirty flush
> >> optimization, and got some nice feedback later from their chat server
> >> that MGLRU's TTL resolved their thrashing issue very well. With
> >> classic LRU they needed a le9 patch downtreamly.
> >>
> >> For many other typical workloads under stress, MGLRU performs
> >> significantly better too (e.g. database, build kernel could be more
> >> than twice as fast), it would be a huge loss to leave it unmaintained.
> >>
> >> Barry also provided some really helpful ideas about MGLRU like
> >> readahead handling. We are also seeing other vendors and people
> >> contributing to MGLRU like Leno and Baolin recently. Things are
> >> looking promising.
> >
> > Guys, can I please make a plea then for you guys to AT LEAST become
> > reviewers in MAINTAINERS please:
> >
> > MEMORY MANAGEMENT - MGLRU (MULTI-GEN LRU)
> > M:	Andrew Morton <akpm@linux-foundation.org>
> >
> > Well Andrew is Andrew :)
> >
> > M:	Axel Rasmussen <axelrasmussen@google.com>
> >
> > git log mm/vmscan.c has 0 results.
> >
> > Axel has however engaged in discussion on
> > https://lore.kernel.org/linux-mm/20260318-mglru-reclaim-v1-0-2c46f9eb0508@tencent.com/
> > recently for example, but not much in 2025 afaict.
> >
> > M:	Yuanchu Xie <yuanchu@google.com>
> >
> > git log mm/vmscan.c shows 1 result from August 13th 2024.
> >
> > Yuanchu has engaged in some MGLRU discussion also recently, here and there.
> >
> > R:	Wei Xu <weixugc@google.com>
> >
> > git log mm/vmscan.c shows 2 results from October 2024.
> >
> > Wei doesn't look to have engaged in discussion on MGLRU recently.
> >
> > L:	linux-mm@kvack.org
> > S:	Maintained
> > W:	http://www.linux-mm.org
> > T:	git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> > F:	Documentation/admin-guide/mm/multigen_lru.rst
> > F:	Documentation/mm/multigen_lru.rst
> > F:	include/linux/mm_inline.h
> > F:	include/linux/mmzone.h
> > F:	mm/swap.c
> > F:	mm/vmscan.c
> > F:	mm/workingset.c
> >
> > It doesn't really feel like MGLRU is currently maintained at all, quite
> > honestly.
> >
> > So I think we need people to step up here.
>
>
> Ans some serious cleanup of the entry to reflect who is actually
> involved nowadays, if at all.
>
> Master of MAINTAINER updates, I assume you'll take care of that?

Ack of course :)

I mean I can suggest a change and cc the various people and we can do it
that way :)

Obviously will want some Acked-by's from those invovled on that though! :)

>
> --
> Cheers,
>
> David

Cheers, Lorenzo