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

[Lorenzo Stoakes <ljs@kernel.org>]

On Tue, Apr 07, 2026 at 12:56:31PM -0400, Gregory Price wrote:
> 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

*nukes entire site from orbit, it's the only way to be sure*

> somewhat trivial work these days via <pick your favorite LLM> with
> reasonably well designed interfaces.

Though to be honest, I did ask Claude to do this with some code before and was
really impressed with how quickly it came up with something.

Buuut I've generally found the code LLMs produce... terrible? Really terrible?
So I think you'd want there to be some level of human improvement there.

And in any case, maybe doing things this way will struggle to really represent
real world cases (lock contention etc.) but OTOH, being able to simulate a high
memory pressure environment with certain parameters even without [the rest of
the kernel] interacting might still be super super useful for diagnosing issues.x

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

*gasp*! But yeah, also yes.

>
> 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.

Yes, adding unit-level tests would be hugely useful.

>
> *throws the pipe into the bikeshed*

*Dives in bikeshed to rescue*

>
> ~Gregory

Cheers, Lorenzo