From: Cyril Hrubis <chrubis@suse.cz>
To: Martin Doucha <mdoucha@suse.cz>
Cc: LTP List <ltp@lists.linux.it>
Subject: Re: [LTP] [RFC] enable OOM protection for the library and test process?
Date: Mon, 13 Dec 2021 17:15:51 +0100 [thread overview]
Message-ID: <Ybdxt/KBUQ6ZKHmY@yuki> (raw)
In-Reply-To: <85404e01-f8f0-7209-8ce1-9e8a2a416e86@suse.cz>
Hi!
> > There are likely more processes that could become unintended targets
> > (e.g. harness process)
> > (if we haven't tried already) Could we make expected victim process
> > more appealing target by tweaking its oom_score/oom_score_adj ?
>
> I'm afraid it won't be that easy. The main cause of OOM killer going
> postal and killing processes with tiny memory footprint is that a
> process executing the mlock() syscall cannot be targeted by OOM killer
> at all. That's a known issue in the kernel with no easy fix.
This is only single test out of at least 10 that can trigger OOM, right?
> You can protect the main test process using oom_score_adj but chances
> are that OOM killer will just kill PID 1 (kernel panic), or find no
> killable process left (also kernel panic).
>
> Protecting the test harness is a bad idea because oom_score_adj is
> inherited by child processes and it'll affect other tests as well. Given
> the nature of OOM tests, I'd rather not assume that the protection will
> be properly removed at the end.
This should be easily doable since the test library forks right before
it executes the test, so we have a single place where the score has to
be reset.
For new library tests there is a process that does nothing but waits for
the actuall test pid to finish and kills it on timeout. It really makes
sense to protect this exact process and maybe even mlock() it into the
memory.
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2021-12-13 16:14 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-13 8:03 [LTP] [RFC] enable OOM protection for the library and test process? Li Wang
2021-12-13 9:32 ` Jan Stancek
2021-12-13 10:18 ` Li Wang
2021-12-13 15:08 ` Cyril Hrubis
2021-12-13 16:06 ` Martin Doucha
2021-12-13 16:15 ` Cyril Hrubis [this message]
2021-12-13 16:59 ` Martin Doucha
2021-12-14 6:46 ` Li Wang
2021-12-14 6:31 ` Li Wang
2021-12-16 3:41 ` [LTP] [PATCH 1/3] lib: add functions to adjust oom score Li Wang
2021-12-16 3:41 ` [LTP] [PATCH 2/3] ltp: enable OOM protection for main and test harness process Li Wang
2021-12-16 7:55 ` Petr Vorel
2021-12-16 9:50 ` Martin Doucha
2021-12-17 1:50 ` Li Wang
2021-12-16 3:41 ` [LTP] [PATCH 3/3] oom: enable OOM protection for mem lib process Li Wang
2021-12-16 7:57 ` Petr Vorel
2021-12-16 7:49 ` [LTP] [PATCH 1/3] lib: add functions to adjust oom score Petr Vorel
2021-12-17 2:02 ` Li Wang
2021-12-17 8:25 ` Petr Vorel
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=Ybdxt/KBUQ6ZKHmY@yuki \
--to=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
--cc=mdoucha@suse.cz \
/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