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

[Gregory Price <gourry@gourry.net>]

On Tue, Apr 07, 2026 at 12:36:36PM +0100, Lorenzo Stoakes wrote:
> >
> > And the current code structure makes it difficult to whittle down the
> > differences methodically.
> >
> > IMO modularization is the best path forward. Giving people the ability
> > to experiment with a la carte combinations of features would make it
> > much easier to actually production test and prove individual ideas.
> 

...

> 
> In a possibly, fantasy ideal world scenario *puffs on dream pipe*, it'd be
> amazing to somehow isolate the reclaim code in such a way that we could
> instrument it for testing purposes.
> 
> E.g. if it could be invoked from userland, or UML, or _something_ and then
> faked out to have a certain configuration of X NUMA nodes and Y GB of RAM
> with Z processes competing with total observability of what's happening in
> the algorithm that could allow for really robust controllable testing and
> regression tests, as well as possibly some form of fuzzing for broken
> reclaim scenarios.
> 
> *Puts dream pipe down*

*picks up the pipe*

At risk of being shot - this kind of stubbing / functional testing is
somewhat trivial work these days via <pick your favorite LLM> with
reasonably well designed interfaces.

   ( read: probably not with the current api n_n;; ).

So to get there, we'd need to agree on the refactor work and interfaces
that make it possible to model the scenarios outside a running kernel.

If we do actually want to move the core to look like:
  - vmscan.c  : core library
  - lru.c     : standard lru
  - mglru.c   : mglru

Might as well consider the functional testing question as well as we
decide what those interfaces look like anyway.

*throws the pipe into the bikeshed*

~Gregory