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

[Axel Rasmussen <axelrasmussen@google.com>]

On Thu, Mar 26, 2026 at 1:02 AM 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?

I think one thing we all agree on at least is, long term, there isn't
really a good argument for having > 1 LRU implementation. E.g., we
don't believe there are just irreconcilable differences, where one
impl is better for some workloads, and another is better for others,
and there is no way the two can be converged.

On that basis, I would be hesitant to add some complex abstraction
layer / reclaim_ops to facilitate having two. It seems ilke it may
make things a bit cleaner in the short term, but long term might make
that end goal harder (because we'd add the task of cleaning up this
abstraction at some point).

My preferred way would be more like:

- Look for opportunities where we can deduplicate code, but without
adding abstraction (e.g., factor out common operations into common
functions both impls can call).
- Identify gaps where MGLRU performs worse than classic LRU, and close them.

We could go the other direction, where we identify places classic LRU
can be improved, and port particular MGLRU features over to it. I
prefer the other way for a couple of reasons;

- My sense is MGLRU is "close", meaning as Kairui said in "average"
cases it is substantially better, and the gaps are both fairly narrow
/ edge-casey, and very solveable.

- Leaving classic LRU alone leaves the option for existing users to
maintain the status quo. If we start porting MGLRU features over to
classic LRU, we may introduce new regressions and break existing
users. Using MGLRU as our working base means we can iterate on it
without as much risk.

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

Very fair concern. Time will tell but I think things are on a much
better trajectory now.

Barry's and Kairui's work here has been great. Suren's team (Android)
is dedicating a full time engineer to MGLRU this year, as I understand
it. I'm planning to do the same myself. I started by spending some
time reviewing some patches last week, and I'm hoping to send some
patches of my own in the next month or two.

I realize just talking about it doesn't mean much, action is needed.
I'm hoping in a few months' time everyone feels much better about the
state of things. :)

>
> I hope that Kairu, Barry, Zicheng and others who are interested int it resolve
> this, however!
>
> Thanks, Lorenzo
>
> [0]:https://lore.kernel.org/linux-mm/aaBsrrmV25FTIkVX@casper.infradead.org/
>
> > --
> > Michal Hocko
> > SUSE Labs