Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Jason Miu <jasonmiu@google.com>
Cc: David Hildenbrand <david@kernel.org>,
	Shuah Khan <shuah@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	Lorenzo Stoakes <ljs@kernel.org>,
	"Liam R . Howlett" <liam@infradead.org>,
	Vlastimil Babka <vbabka@kernel.org>,
	Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Michal Hocko <mhocko@suse.com>, Greg Thelen <gthelen@google.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org
Subject: Re: [RFC PATCH 0/3] selftests: mm: introduce page allocation stall reproducer
Date: Thu, 20 Aug 2026 17:03:48 -0700	[thread overview]
Message-ID: <20260820170348.48f04ed654dce5193ca3a532@linux-foundation.org> (raw)
In-Reply-To: <20260819070538.2404983-1-jasonmiu@google.com>

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?



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.



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.


Sashiko said hello:
	https://sashiko.dev/#/patchset/20260819070538.2404983-1-jasonmiu@google.com


In [patch 1/3], s/__GFP_NOFAIL// and s/cond_resched()//.


  parent reply	other threads:[~2026-08-21  0:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-19  7:05 [RFC PATCH 0/3] selftests: mm: introduce page allocation stall reproducer Jason Miu
2026-08-19  7:05 ` [PATCH 1/3] lib/test_mempress_timer: add module to generate kernel allocation pressure Jason Miu
2026-08-19  7:05 ` [PATCH 2/3] selftests: mm: add script to induce userspace memory contention Jason Miu
2026-08-19  7:05 ` [PATCH 3/3] selftests: mm: add script for memory allocation stall test Jason Miu
2026-08-21  0:03 ` Andrew Morton [this message]
2026-08-21  9:53   ` [RFC PATCH 0/3] selftests: mm: introduce page allocation stall reproducer David Hildenbrand (Arm)
2026-08-21 10:44     ` Lorenzo Stoakes (ARM)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260820170348.48f04ed654dce5193ca3a532@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=david@kernel.org \
    --cc=gthelen@google.com \
    --cc=jasonmiu@google.com \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@suse.com \
    --cc=rientjes@google.com \
    --cc=rppt@kernel.org \
    --cc=shakeel.butt@linux.dev \
    --cc=shuah@kernel.org \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox