All of
 help / color / mirror / Atom feed
From: Tetsuo Handa <>
To: Sergey Senozhatsky <>,
	Michal Hocko <>
Cc: Johannes Weiner <>,,,,,,,,
	Andrew Morton <>,
	Petr Mladek <>,
	Sergey Senozhatsky <>,
	Steven Rostedt <>,
	syzbot <>
Subject: Re: [PATCH v3] mm: memcontrol: Don't flood OOM messages with no eligible task.
Date: Thu, 18 Oct 2018 20:58:53 +0900	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20181018081352.GA438@jagdpanzerIV>

On 2018/10/18 17:13, Sergey Senozhatsky wrote:
> On (10/18/18 09:56), Michal Hocko wrote:
>> On Thu 18-10-18 15:10:18, Sergey Senozhatsky wrote:
>> [...]
>>> and let's hear from MM people what they can suggest.
>>> Michal, Andrew, Johannes, any thoughts?
>> I have already stated my position. Let's not reinvent the wheel and use
>> the standard printk throttling. If there are cases where oom reports
>> cause more harm than good I am open to add a knob to allow disabling it
>> altogether (it can be even fine grained one to control whether to dump
>> show_mem, task_list etc.).

Moderate OOM reports with making progress is good.
But OOM reports without making progress is bad.

> A knob might do.
> As well as /proc/sys/kernel/printk tweaks, probably. One can even add
> echo "a b c d" > /proc/sys/kernel/printk to .bashrc and adjust printk
> console levels on login and rollback to old values in .bash_logout
> May be.

That can work for only single login with root user case.
Not everyone logs into console as root user.

It is pity that we can't send kernel messages to only selected consoles
(e.g. all messages are sent to netconsole, but only critical messages are
sent to local consoles).

>> But please let's stop this dubious one-off approaches.
> OK. Well, I'm not proposing anything actually. I didn't even
> realize until recently that Tetsuo was talking about "user
> interaction" problem; I thought that his problem was stalled
> RCU.

The "stalled RCU" was the trigger for considering this problem.
Nobody has seriously considered what we should do when the memcg OOM killer
cannot make progress. If the OOM killer cannot make progress, we need to
handle situations where the OOM-unkillable process cannot solve the memcg OOM
situation. Then, the poorest recovery method is that the root user enters
commands for recovery (It might be to increase the memory limit. It might be
to move to a different cgroup. It might be to gracefully terminate the
OOM-unkillable process.) from "consoles" where the OOM messages are sent.

If we start from the worst case, it is obvious that we need to make sure that
the OOM messages do not disturb "consoles" so that the root user can enter
commands for recovery. That boils down to a "user interaction" problem.
Not limiting

  "%s invoked oom-killer: gfp_mask=%#x(%pGg), nodemask=%*pbl, order=%d, oom_score_adj=%hd\n"
  "Out of memory and no killable processes...\n"

is very annoying.

And I really can't understand why Michal thinks "handling this requirement" as
"make the code more complex than necessary and squash different things together".
Satisfying the most difficult error path handling is not a simple thing.

  reply	other threads:[~2018-10-18 11:59 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-17 10:06 Tetsuo Handa
2018-10-17 10:28 ` Michal Hocko
2018-10-17 11:17   ` Sergey Senozhatsky
2018-10-17 11:29     ` Michal Hocko
2018-10-18  2:46     ` Tetsuo Handa
2018-10-18  2:46       ` Tetsuo Handa
2018-10-18  4:27       ` Sergey Senozhatsky
2018-10-18  5:26         ` Tetsuo Handa
2018-10-18  5:26           ` Tetsuo Handa
2018-10-18  6:10           ` Sergey Senozhatsky
2018-10-18  7:56             ` Michal Hocko
2018-10-18  8:13               ` Sergey Senozhatsky
2018-10-18 11:58                 ` Tetsuo Handa [this message]
2018-10-18 23:54                   ` Sergey Senozhatsky
2018-10-19 10:35                     ` Tetsuo Handa
2018-10-19 10:35                       ` Tetsuo Handa
2018-10-23  0:47                       ` Sergey Senozhatsky
2018-10-23  8:37                       ` Petr Mladek
2018-10-23  8:54                         ` Michal Hocko
2018-10-18 14:30         ` Petr Mladek
2018-10-19  0:18           ` Tetsuo Handa
2018-10-23  8:21             ` Petr Mladek
2018-10-23 10:23               ` Tetsuo Handa
2018-10-18  6:55       ` Michal Hocko
2018-10-18 10:37         ` Tetsuo Handa
2018-10-18 11:23           ` Michal Hocko

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH v3] mm: memcontrol: Don'\''t flood OOM messages with no eligible task.' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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.