From: Michal Hocko <mhocko@kernel.org>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
linux-mm@kvack.org, syzkaller-bugs@googlegroups.com, guro@fb.com,
kirill.shutemov@linux.intel.com, linux-kernel@vger.kernel.org,
rientjes@google.com, yang.s@alibaba-inc.com,
Andrew Morton <akpm@linux-foundation.org>,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Petr Mladek <pmladek@suse.com>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
syzbot <syzbot+77e6b28a7a7106ad0def@syzkaller.appspotmail.com>
Subject: Re: [PATCH v3] mm: memcontrol: Don't flood OOM messages with no eligible task.
Date: Wed, 17 Oct 2018 12:28:21 +0200 [thread overview]
Message-ID: <20181017102821.GM18839@dhcp22.suse.cz> (raw)
In-Reply-To: <1539770782-3343-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp>
On Wed 17-10-18 19:06:22, Tetsuo Handa wrote:
> syzbot is hitting RCU stall at shmem_fault() [1].
> This is because memcg-OOM events with no eligible task (current thread
> is marked as OOM-unkillable) continued calling dump_header() from
> out_of_memory() enabled by commit 3100dab2aa09dc6e ("mm: memcontrol:
> print proper OOM header when no eligible victim left.").
>
> Michal proposed ratelimiting dump_header() [2]. But I don't think that
> that patch is appropriate because that patch does not ratelimit
>
> "%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"
>
> messages which can be printed for every few milliseconds (i.e. effectively
> denial of service for console users) until the OOM situation is solved.
>
> Let's make sure that next dump_header() waits for at least 60 seconds from
> previous "Out of memory and no killable processes..." message. Michal is
> thinking that any interval is meaningless without knowing the printk()
> throughput. But since printk() is synchronous unless handed over to
> somebody else by commit dbdda842fe96f893 ("printk: Add console owner and
> waiter logic to load balance console writes"), it is likely that all OOM
> messages from this out_of_memory() request is already flushed to consoles
> when pr_warn("Out of memory and no killable processes...\n") returned.
> Thus, we will be able to allow console users to do what they need to do.
>
> To summarize, this patch allows threads in requested memcg to complete
> memory allocation requests for doing recovery operation, and also allows
> administrators to manually do recovery operation from console if
> OOM-unkillable thread is failing to solve the OOM situation automatically.
Could you explain why this is any better than using a well established
ratelimit approach?
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2018-10-17 10:28 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-17 10:06 [PATCH v3] mm: memcontrol: Don't flood OOM messages with no eligible task Tetsuo Handa
2018-10-17 10:28 ` Michal Hocko [this message]
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
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 \
--in-reply-to=20181017102821.GM18839@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=pmladek@suse.com \
--cc=rientjes@google.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=syzbot+77e6b28a7a7106ad0def@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=yang.s@alibaba-inc.com \
/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.