From: Tetsuo Handa <email@example.com> To: Sergey Senozhatsky <firstname.lastname@example.org>, Michal Hocko <email@example.com> Cc: Johannes Weiner <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, Andrew Morton <firstname.lastname@example.org>, Petr Mladek <email@example.com>, Sergey Senozhatsky <firstname.lastname@example.org>, Steven Rostedt <email@example.com>, syzbot <firstname.lastname@example.org> 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: <email@example.com> (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.
next prev parent 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: 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH v3] mm: memcontrol: Don'\''t flood OOM messages with no eligible task.' \ /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
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.