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

[Gregory Price <gourry@gourry.net>]

On Tue, Apr 07, 2026 at 06:30:55PM +0100, Lorenzo Stoakes wrote:
> 
> > 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
>

There is a concern people start looking at these tests as signal for
performance regressions - which is neither meaningful nor useful
(unless you fundamentally break list iteration or something).

But for trivial cases, you'd at least like to know under strongly
controlled aging and reclaim scenarios that anon/file memory is
reclaimed in a balanced manner - just as an example. 

If something breaks THAT assumption, you know there's a logic issue.

Likewise with comparisons between LRU and MGLRU.  It might be easier to
identify the behavioral divergences that way.

But i fear the whole page-table walk thing makes all of this a
non-starter.  That's turns into stubbing out like rmap and such.

~Gregory