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 09:17:17PM +0800, Kairui Song wrote:
> On Thu, Mar 26, 2026 at 8:31 PM Lorenzo Stoakes (Oracle) <ljs@kernel.org> wrote:
> >
> > +cc Gregory
> >
> > On Thu, Mar 26, 2026 at 08:06:13PM +0800, Kairui Song wrote:
> > > On Thu, Mar 26, 2026 at 10:05 AM Andrew Morton
> > > <akpm@linux-foundation.org> 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.
> > > >
> > > > 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 personally also agree on that, so far I'm not aware of any major
> > > issues with MGLRU except some corner cases that are not hard to fix.
> > > Once these are done, I don't see the need for more complexity.
> >
> > Well... :)
> >
> > What about the issues Gregory raised here?
> >
> > https://lore.kernel.org/linux-mm/aaXM7xNSJaJBsety@gourry-fedora-PF4VCD3F/
>
> Hi,
>
> Thanks for linking Gregory's mail.
>
> I'm not quite sure I fully get what the concern is, I'll try to
> address the main points I see. Regarding the bi-modal distributions,
> it's very workload-dependent, and the reclamation still performs well
> with that distributions. So I think that's not really a problem?
>
> The heuristics are a bit confusing and intertwined (gen number as
> flags for atomic update and avoid LRU lock, tight coupling with
> generational aging, etc.), decoupling them cleanly without hurting
> performance is tricky, and the current approach has worked
> dramatically well. Cleanup the code structure might be helpful?
>
> Many distros have been running MGLRU by default for years now and the
> feedback (plus our own production experience) has been very positive.
> There are indeed some known rough edges, under-protected file cache,
> ineffective swappiness, flag usage, etc. some of which I listed here
> [1]. I believe they're all fixable, and once addressed MGLRU should be
> a solid base.
>
> Right, I realized after re-reading that some of these really are not
> really easy to fix or improve... sorry for my earlier reply, guess I'm
> too sleepy today and not thinking clearly :P, my apologies.
>
> [1] https://lore.kernel.org/linux-mm/CAMgjq7BoekNjg-Ra3C8M7=8=75su38w=HD782T5E_cxyeCeH_g@mail.gmail.com/

Thanks, well that's good to hear.

I broadly agree with Shakeel's proposals for the incremental improvement of
the LRU code, and I think that and fixing MAINTAINERS (*ahem*) will
seriously help move us forwards with this.

I wonder also if we shouldn't have a document on this somewhere in the
kernel to lay out the differences, improvements, how the gen numbers work
etc.?

Cheers, Lorenzo