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

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Fri, Aug 21, 2026 at 11:53:57AM +0200, David Hildenbrand (Arm) wrote:
> On 8/21/26 02:03, Andrew Morton wrote:
> > On Wed, 19 Aug 2026 00:05:35 -0700 Jason Miu <jasonmiu@google.com> 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?

Oh HELL no.

Only C in the selftests please.

And python is replete with 'getting it to run locally' issues. I have venv
PTSD...

>
> >
> >
> > 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.

Agreed. Separate please.

Stress tests are just asking for flakes :) they are useful + important but
something different.

>
> >
> >
> >
> > 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.

Yes.

>
>
> --
> Cheers,
>
> David

--
Cheers, Lorenzo