From: Qian Cai <cai@lca.pw>
To: Michal Hocko <mhocko@kernel.org>, linux-mm@kvack.org
Cc: Andrew Morton <akpm@linux-foundation.org>,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
David Rientjes <rientjes@google.com>,
LKML <linux-kernel@vger.kernel.org>,
Michal Hocko <mhocko@suse.com>
Subject: Re: [RFC PATCH] mm, oom: disable dump_tasks by default
Date: Tue, 03 Sep 2019 11:02:46 -0400 [thread overview]
Message-ID: <1567522966.5576.51.camel@lca.pw> (raw)
In-Reply-To: <20190903144512.9374-1-mhocko@kernel.org>
On Tue, 2019-09-03 at 16:45 +0200, Michal Hocko wrote:
> From: Michal Hocko <mhocko@suse.com>
>
> dump_tasks has been introduced by quite some time ago fef1bdd68c81
> ("oom: add sysctl to enable task memory dump"). It's primary purpose is
> to help analyse oom victim selection decision. This has been certainly
> useful at times when the heuristic to chose a victim was much more
> volatile. Since a63d83f427fb ("oom: badness heuristic rewrite")
> situation became much more stable (mostly because the only selection
> criterion is the memory usage) and reports about a wrong process to
> be shot down have become effectively non-existent.
Well, I still see OOM sometimes kills wrong processes like ssh, systemd
processes while LTP OOM tests with staight-forward allocation patterns. I just
have not had a chance to debug them fully. The situation could be worse with
more complex allocations like random stress or fuzzy testing.
>
> dump_tasks can generate a lot of output to the kernel log. It is not
> uncommon that even relative small system has hundreds of tasks running.
> Generating a lot of output to the kernel log both makes the oom report
> less convenient to process and also induces a higher load on the printk
> subsystem which can lead to other problems (e.g. longer stalls to flush
> all the data to consoles).
It is only generate output for the victim process where I tested on those large
NUMA machines and the output is fairly manageable.
>
> Therefore change the default of oom_dump_tasks to not print the task
> list by default. The sysctl remains in place for anybody who might need
> to get this additional information. The oom report still provides an
> information about the allocation context and the state of the MM
> subsystem which should be sufficient to analyse most of the oom
> situations.
>
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---
> mm/oom_kill.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index eda2e2a0bdc6..d0353705c6e6 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -52,7 +52,7 @@
>
> int sysctl_panic_on_oom;
> int sysctl_oom_kill_allocating_task;
> -int sysctl_oom_dump_tasks = 1;
> +int sysctl_oom_dump_tasks;
>
> /*
> * Serializes oom killer invocations (out_of_memory()) from all contexts to
next prev parent reply other threads:[~2019-09-03 15:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-03 14:45 [RFC PATCH] mm, oom: disable dump_tasks by default Michal Hocko
2019-09-03 15:02 ` Qian Cai [this message]
2019-09-03 15:13 ` Michal Hocko
2019-09-03 15:32 ` Qian Cai
2019-09-03 19:12 ` Michal Hocko
2019-09-05 16:10 ` Qian Cai
[not found] ` <8ea5da51-a1ac-4450-17d9-0ea7be346765@i-love.sakura.ne.jp>
2019-09-05 21:21 ` Qian Cai
[not found] ` <192f2cb9-172e-06f4-d9e4-a58b5e167231@i-love.sakura.ne.jp>
2019-09-06 13:08 ` Qian Cai
[not found] ` <7eada349-90d0-a12f-701c-adac3c395e3c@i-love.sakura.ne.jp>
2019-09-06 13:48 ` Qian Cai
2019-09-06 13:49 ` Michal Hocko
2019-09-03 20:52 ` Tetsuo Handa
2019-09-04 5:40 ` Michal Hocko
2019-09-04 20:04 ` David Rientjes
2019-09-05 13:39 ` Tetsuo Handa
2019-09-05 14:08 ` Michal Hocko
2019-09-06 10:46 ` Tetsuo Handa
2019-09-06 11:02 ` Michal Hocko
2019-09-06 11:11 ` Tetsuo Handa
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=1567522966.5576.51.camel@lca.pw \
--to=cai@lca.pw \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=mhocko@suse.com \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=rientjes@google.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.