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

[David Hildenbrand (Arm)]

On 8/3/26 00:19, David Rientjes wrote:
> 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?

Yes. lib/ is just absolutely the wrong place for that.

Maybe lib/tests/mm

But then, I wonder if they could just be somewhere in tests/ directly ...

Anyhow, it was also raised whether some of these could be written as kunit
tests. It's been a long time since I worked on these, so just mentioning it.

-- 
Cheers,

David