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

[Usama Anjum <usama.anjum@arm.com>]

On 10/09/2026 10:38 am, David Hildenbrand (Arm) wrote:
> 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.

I also think it would be best to try to add them as kunit. I'm not exactly sure if
kunit would accept such benchmark kind of code. Some research is required there.

Thanks,
Usama