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 10:24:28AM -0500, Gregory Price wrote:
> ... snip snip snip ...
>
> > >
> > > How Do We Get There
> > > -------------------
> > >
> > > Do we merge the two mechanisms feature by feature, or do we prioritize
> > > moving MGLRU to the pluggable model then follow with LRU once we are
> > > happy with the result?
> >
> > Absolutely by a distance the first is preferable. The pluggability is
> > controversial here and needs careful consideration.
> >
>
> Pluggability asside - I do not think merging these two things "feature
> by feature" is actually feasible (I would be delighted to be wrong).
>
> Many MGLRU "features" solve problems that MGLRU invents for itself.
>
> Take MGLRU's PID controller - its entire purpose is to try to smooth out
> refault rates and "learn" from prior mistakes - but it's fundamentally
> tied to MGLRU's aging system, and the aging systems differ greatly.
>
>   - LRU:   actual lists - active/inactive - that maintain ordering
>   - MGLRU: "generations", "inter-generation tiers", aging-in-place
>
> "Merging" this is essentially inventing something completely new - or
> more reasonably just migrating everyone to MGLRU.
>
> In terms of managing risk, it seems far more reasonable to either split
> MGLRU off into its own file and formalize the interface (ops), or simply
> rip it out and let each individual feature fight its way back in.

But _surely_ (and Shakeel can come back on this I guess) there are things that
are commonalities.

In any case we can all agree that MGLRU cohabiting with classical reclaim is not
a happy household one way or another.

Maybe a stage 1 can be to separate stuff into another file, because that'd
actually be pretty easy to do for a fair bit of it, surely?

Can use mm/internal.h to handle stuff that has to link one with other?

>
> ~Gregory

Cheers, Lorenzo