Linux Test Project
 help / color / mirror / Atom feed
From: Andrea Cervesato via ltp <ltp@lists.linux.it>
To: "Li Wang" <li.wang@linux.dev>
Cc: Linux Test Project <ltp@lists.linux.it>
Subject: Re: [LTP] [PATCH] memcg_stress: survive OOM by targeting the stressors
Date: Sat, 04 Jul 2026 07:50:19 +0000	[thread overview]
Message-ID: <6a48bb3c.bc1d6770.394c18.b078@mx.google.com> (raw)
In-Reply-To: <aki2AjzuU7_ayxrZ@linux.dev>

Hi Li,

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

this patch was sent with a wrong assumption indeed. As you can see
from the log, the OOM message is wrong and I pasted the wrong example :)

But this raised a good point that I think you spotted quite well. It
would be nice to implement this indeed, since shell tests are often
causing issues when it comes to containers or stressing the memory.

I will leave to @Petr the last word because he's more expert than me
on the shell tests.

Thanks,
--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2026-07-04  7:50 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 ` [LTP] [PATCH] " Li Wang
2026-07-04  7:50   ` Andrea Cervesato via ltp [this message]
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=6a48bb3c.bc1d6770.394c18.b078@mx.google.com \
    --to=ltp@lists.linux.it \
    --cc=andrea.cervesato@suse.com \
    --cc=li.wang@linux.dev \
    /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