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

[Shakeel Butt <shakeel.butt@linux.dev>]

On Thu, Mar 26, 2026 at 04:24:04PM +0100, Michal Hocko wrote:
> On Thu 26-03-26 06:44:07, Shakeel Butt wrote:
> > On Thu, Mar 26, 2026 at 08:12:10AM +0100, Michal Hocko wrote:
> > > On Wed 25-03-26 14:06:37, Shakeel Butt wrote:
> [...]
> > > I think we should focus to make a single canonical reclaim
> > > implementation work well. I.e. we deal with most (or ideally all) known
> > > regressions of MGLRU. 
> > 
> > Here we disagree on the approach or steps to reach the single canonical reclaim
> > implementation. MGLRU is a plethora of different mechanisms and policies and it
> > never went through rigorous evaluation for each of those mechanisms and
> > policies individually. To me that needs to be done to have one solution. 
> 
> If my recollection is correct from the LSFMM (2022) there was a promise that
> MGLRU architecture should allow to add extension and eventually
> supersede traditional LRU. If we do not see that happening then we
> should re-evaluate current MGRLU approach. I do not think we want to
> build reclaim_ext architecture on top of the current code. Or are you
> suggesting to achieve MGLRU through reclaim_ext?

My main objective is to unify the reclaim i.e. one reclaim algorithm/mechanism
and then (later) provide a framework where folks/kernel-engs/researchers can
experiment with new techniques/algorithms without changing the core reclaim.

Regarding MGLRU, after unification something from MGLRU remains which does not
makes sense to put in the core reclaim, that can be provided through the
framework. For reclaim_ext, I just like the name, looks fancy :).