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:30 PM Gregory Price <gourry@gourry.net> wrote:
>
> On Thu, Mar 26, 2026 at 01:02:02PM -0700, Axel Rasmussen wrote:
> >
> > 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.
> >
>
> I absolutely believe there are irreconcilable differences - but not in
> the sense that one is better or worse, but in the sense that features
> from one cannot work in the other.

Right, agreed. I mean a case where we have workloads A and B, such
that there does not exist an implementation that can serve both well.
If such workloads were "common" to me that would justify a reclaim_ops
/ pluggable abstraction layer. My thesis is that they are "not
common", so I'm a bit skeptical the abstraction is worth it.

>
> > - 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.
> >
>
> This is a really, really bold claim.  So much of this is workload
> dependent, and LRU has decades of battle-testing while MGLRU has barely
> been around 4 years.

Fair. My basic thinking is, MGLRU is enabled by default in some
(admittedly, not all) major distros like Fedora or Arch. From that, we
have some various regression reports on the mailing list, but to
Kairui's point, nothing that looks super hard to resolve.

Then again we can always be surprised later / as the footprint expands. :)

>
> ~Gregory