From: Li Wang <li.wang@linux.dev>
To: Andrea Cervesato <andrea.cervesato@suse.de>
Cc: Linux Test Project <ltp@lists.linux.it>
Subject: Re: [LTP] [PATCH] memcg_stress: survive OOM by targeting the stressors
Date: Sat, 4 Jul 2026 15:31:23 +0800 [thread overview]
Message-ID: <aki2AjzuU7_ayxrZ@linux.dev> (raw)
In-Reply-To: <20260703-fix_memcg_stress-v1-1-93bd09a62446@suse.com>
Hi Andrea,
Andrea Cervesato wrote:
> From: Andrea Cervesato <andrea.cervesato@suse.com>
>
> The single-cgroup subtest intentionally lets one process fault in the
> whole memory budget to push the system to its memory ceiling, so hitting
> the OOM killer is an expected part of the stress. The problem is that the
> OOM killer could reap the driver script, turning that expected pressure
> into a spurious TBROK.
>
> Mark the stress processes as the preferred OOM victims. A killed stressor
> is already reaped and cleaned up by the test, while the driver survives
> and reports the result.
>
> Fixes: 02961a7b2bb4 ("memcg_stress_test.sh: Fix reserved mem calculate")
> Signed-off-by: Andrea Cervesato <andrea.cervesato@suse.com>
> ---
> On some systems this might happens:
>
> [ 244.207623][T117130] kirk[3061]: memcg_stress: start (command: memcg_stress_test.sh)
> [ 244.391438][T117164] memcg_stress_te (117164): drop_caches: 3
> [ 1444.509722][T119900] kirk[3061]: memcg_stress: end (returncode: -1)
> [ 1444.629434][T119934] kirk[3061]: memcg_control: start (command: memcg_control_test.sh)
> [ 1445.856012][T120020] mem_process invoked oom-killer: gfp_mask=0xcc0(GFP_KERNEL), order=0, oom_score_adj=0
I agree with the underlying goal, keep the driver alive and let the
stressors absorb the OOM pressure, but I'd like to suggest a different
way that mirrors what we already do in the C harness, and that fixes
this at the lib level rather than in the individual test.
In lib/tst_test.c we don't raise the score of the stress/test processes.
Instead we protect the harness and then explicitly drop that protection
in the child before it runs the actual test:
$ grep -A 8 -B 9 tst_enable_oom_protection lib/tst_test.c
void tst_run_tcases(int argc, char *argv[], struct tst_test *self)
{
unsigned int test_variants = 1;
struct utsname uval;
tst_test = self;
do_setup(argc, argv);
tst_enable_oom_protection(context->lib_pid);
SAFE_SIGNAL(SIGALRM, alarm_handler);
SAFE_SIGNAL(SIGUSR1, heartbeat_handler);
tst_res(TINFO, "LTP version: "LTP_VERSION);
uname(&uval);
tst_res(TINFO, "Tested kernel: %s %s %s", uval.release, uval.version, uval.machine);
$ grep -A 8 -B 9 tst_disable_oom_protection lib/tst_test.c
alarm(context->overall_time);
show_failure_hints = 1;
test_pid = fork();
if (test_pid < 0)
tst_brk(TBROK | TERRNO, "fork()");
if (!test_pid) {
tst_disable_oom_protection(0);
SAFE_SIGNAL(SIGALRM, SIG_DFL);
SAFE_SIGNAL(SIGUSR1, SIG_DFL);
SAFE_SIGNAL(SIGTERM, SIG_DFL);
SAFE_SIGNAL(SIGINT, SIG_DFL);
SAFE_SETPGID(0, 0);
testrun();
}
The important detail is that oom_score_adj is inherited across fork.
So the model is: the library process sets itself to -1000, and child
resets itself back to 0 before doing any real work. The harness survives,
the workload stays a normal OOM candidate.
What do you think about doing this in the shell lib so all shell
tests benefit, rather than only memcg_stress?
--
Regards,
Li Wang
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2026-07-04 7:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-03 8:23 [LTP] [PATCH] memcg_stress: survive OOM by targeting the stressors Andrea Cervesato
2026-07-03 10:01 ` [LTP] " linuxtestproject.agent
2026-07-04 7:31 ` Li Wang [this message]
2026-07-04 7:50 ` [LTP] [PATCH] " Andrea Cervesato via ltp
2026-07-04 9:15 ` Li Wang
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=aki2AjzuU7_ayxrZ@linux.dev \
--to=li.wang@linux.dev \
--cc=andrea.cervesato@suse.de \
--cc=ltp@lists.linux.it \
/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