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 08:37:06PM +0800, Kairui Song wrote:
> On Thu, Mar 26, 2026 at 4:02 PM Lorenzo Stoakes (Oracle) <ljs@kernel.org> wrote:
> >
> > On Thu, Mar 26, 2026 at 08:03:34AM +0100, Michal Hocko wrote:
> > > On Wed 25-03-26 19:05:47, Andrew Morton wrote:
> > > > On Wed, 25 Mar 2026 14:06:37 -0700 Shakeel Butt <shakeel.butt@linux.dev> wrote:
> > > >
> > > > > We should unify both algorithms into a single code path.
> > > >
> > > > I'm here to ask the questions which others fear will sound dumb.
> > >
> > > Not dumb at all and recently discussed here https://lore.kernel.org/all/CAMgjq7AkYOtUL2HuZjBu5dJw=RTL7W2L1+zVv=SCOyHKYwc3AA@mail.gmail.com/T/#u
> > >
> > > > Is it indeed the plan to maintain both implementations?  I thought the
> > > > long-term ambition was to knock MGLRU into shape and to drop the legacy LRU?
> > >
> > > Yes, but MGLRU is not there yet and with development pace last year or
> > > so we are not much closer than at the time MGLRU has been merged
> > > unfortunatelly.
> >
> > 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.

Thanks, Lorenzo