Re: [patch 0/3] lib: add synthetic MM benchmarks

[David Rientjes <rientjes@google.com>]

On Fri, 31 Jul 2026, David Hildenbrand (Arm) wrote:

> On 7/31/26 06:26, David Rientjes wrote:
> > A blast to the past :)
> > 
> 
> :)
> 
> > We've been carrying these synthetic benchmarks in our kernel tree since 
> > 2009 because they've been helpful to identify regressions in hot paths, as 
> > well as quantifying any improvements that have been made for new changes.  
> > Hopefully they can be useful to others as well.
> > 
> > The synthetic benchmarks are run by loading the module at runtime.  The 
> > modprobe will fail intentionally so that the module gets insta-unloaded.  
> > The test results are emitted to the kernel log.
> 
> 
> Ideally we'd have an easy way to actually use them in autoamtic tests.
> 
> E.g., loading fails -> error, loading works -> no error (and unload)
> 
> > 
> > Proposed with permission from Christoph.
> > ---
> >  lib/Kconfig.debug    |  30 ++++
> >  lib/Makefile         |   3 +
> >  lib/test_pagealloc.c | 337 ++++++++++++++++++++++++++++++++++++++
> >  lib/test_slab.c      | 375 +++++++++++++++++++++++++++++++++++++++++++
> >  lib/test_vmstat.c    |  95 +++++++++++
> >  5 files changed, 840 insertions(+)
> >  create mode 100644 lib/test_pagealloc.c
> >  create mode 100644 lib/test_slab.c
> >  create mode 100644 lib/test_vmstat.c
> 
> This looks similar to tools/testing/selftests/mm/test_vmalloc.sh and friends,
> that can actually be executed as part of our selftests and do a modprobe.
> 
> Can we have similar scripts to execute them?
> 

Thanks for looking at these tests!

Good call, I agree these could be loaded with a wrapper similar to 
test_vmalloc.sh.

All three of these tests don't take module parameters (yet?) so right now 
this wrapper would just do the equivalent of check_test_requirements(), 
usage(), and run_test() where we'd pass in a single option for now, 
"performance".

> But I also wonder if these test modules could be placed then in
> tools/testing/selftests/mm/ instead (or some subdirectory for test modules).
> 

I thought about the same and just followed what appears to be the standard 
convention (like test_vmalloc above) for lib/ for now.  If they should all 
be moved under tools/ somewhere, perhaps we handle that in a separate 
series?

> Last but not least: MAINTAINERS should cover them.
> 

Ack.

> -- 
> Cheers,
> 
> David
>