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

[Kairui Song]

On Thu, Mar 26, 2026 at 8:31 PM Lorenzo Stoakes (Oracle) <ljs@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > On Wed, 25 Mar 2026 14:06:37 -0700 Shakeel Butt <shakeel.butt@xxxxxxxxx> 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@xxxxxxxxxxxxxx/