All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Stancek <jstancek@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] Taunt OOM killer in fork12 setup()
Date: Fri, 31 Jan 2020 04:37:42 -0500 (EST)	[thread overview]
Message-ID: <1041474174.5093428.1580463462902.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <CAEemH2f7s+q1upnaikCnQZSqxb-xgdN73aPxhKhLo2i5_M7FkA@mail.gmail.com>


----- Original Message -----
> 
> 
> On Fri, Jan 31, 2020 at 12:13 AM Martin Doucha < mdoucha@suse.cz > wrote:
> 
> 
> On a system with low memory, fork12 can trigger OOM killer before it hits
> any fork() limits. The OOM killer might accidentally kill e.g. the parent
> shell and external testing tools will assume the test failed.
> 
> Set high oom_score_adj on the fork12 process so that the OOM killer focuses
> on it and its children.
> 
> It sounds more like the OOM-Killer defect but not fork12.

Badness score is based on proportion of rss/swap. It doesn't seem like
defect to me, we just quickly spawn many small tasks.

> What we do for that
> is to protect the parent shell and its harness to avoid oom_kill_process()
> acting on them.
> 
> On the other side, if we do raise the oom score of fork12, that would not
> guarantee OOM-Killer do right evaluation but just makes fork12 easily to be
> killed in testing.

fork12 is not an OOM test, so I don't see problem with this. We only need OOM
to kill something we don't care about, in case it triggers.

I'd move oom_score_adj after fork, so only child processes are better target,
not the parent.


  reply	other threads:[~2020-01-31  9:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-30 16:13 [LTP] [PATCH] Taunt OOM killer in fork12 setup() Martin Doucha
2020-01-31  9:14 ` Li Wang
2020-01-31  9:37   ` Jan Stancek [this message]
2020-01-31  9:47     ` Li Wang
2020-01-31 12:40     ` Martin Doucha
2020-01-31 14:20       ` Li Wang
2020-02-07 14:54     ` [LTP] [PATCH v2] " Martin Doucha
2020-02-07 14:56       ` Jan Stancek
2020-02-07 16:06       ` Cyril Hrubis

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=1041474174.5093428.1580463462902.JavaMail.zimbra@redhat.com \
    --to=jstancek@redhat.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.