Re: [RFC PATCH 0/3] selftests: mm: introduce page allocation stall reproducer

[David Hildenbrand (Arm)]

On 8/21/26 02:03, Andrew Morton wrote:
> On Wed, 19 Aug 2026 00:05:35 -0700 Jason Miu <jasonmiu@xxxxxxxxxx> wrote:
> 
>> Background
>> ==========
>> Under severe system memory pressure, system unresponsiveness often 
>> occurs due to page allocation stalls. In commit 94e0bcde055e ("mm, 
>> page_alloc: reintroduce page allocation stall warning"), David Rientjes 
>> introduced a warning mechanism to emit a kernel log when a page 
>> allocation takes longer than 10 seconds. This log is used to correlate
>> a frozen system with the system memory state at the time of failure.
>>
>> To further debug and analyze these allocation stalls, we need a 
>> reproducible test case. This patch series introduces a new selftest 
>> designed to artificially mimic the severe memory pressure scenarios 
>> seen in production, allowing us to observe the resulting allocation 
>> stalls.
> 
> Interesting.
> 
>>  lib/Kconfig.debug                             |  11 +
>>  lib/Makefile                                  |   1 +
>>  lib/test_mempress_timer.c                     | 140 +++++++++++
>>  .../testing/selftests/mm/page_alloc_stall.sh  |  80 ++++++
>>  .../selftests/mm/page_alloc_stall_pressure.py | 235 ++++++++++++++++++
>>  5 files changed, 467 insertions(+)
>>  create mode 100644 lib/test_mempress_timer.c
>>  create mode 100644 tools/testing/selftests/mm/page_alloc_stall.sh
>>  create mode 100644 tools/testing/selftests/mm/page_alloc_stall_pressure.py
> 
> Nothing fits very well, does it?
> 

Why are we mixing python and sh?

> 
> 
> selftests is for quick tests which are run by run_kselftest.sh.  You
> had to place it in selftests because there isn't anywhere obvious for
> it to live.
> 
> So I suggest a brand new tools/testing/stresstests/mm.  If we create
> this, people will jump on it and start adding things which presently
> reside in their personal collections.

There was recently a discussion around performance tests, and one thought was to
not carry these in the kernel tree at all.

Stresstests, not sure.

So agreed, that this shouldn't be an ordinary selftests (nothing we would want
to run autoamtically), but I am also not 100% sure about having performance /
stress tests in the kernel tree. It's all stuff we have to maintain and drag along.

> 
> 
> 
> I can't say I like "mempress".  Is "memory_pressure" too wordy?
> 
> 
> 
> All of lib/test*.c shouldn't be in lib/.  lib/ is for library code! 
> Again, we put them there because people are shy about doing mkdir.

There were recent discussions where I raised the same. I would prefer if testing
kernel modules are somewhere in tools/testing/ if possible.


-- 
Cheers,

David