linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Ricardo Cañuelo" <ricardo.canuelo@collabora.com>
To: akpm@linux-foundation.org
Cc: kernel@collabora.com, hch@lst.de, guro@fb.com,
	rientjes@google.com, mcgrof@kernel.org, keescook@chromium.org,
	yzaikin@google.com, linux-mm@kvack.org,
	sergey.senozhatsky@gmail.com, pmladek@suse.com,
	rostedt@goodmis.org, mhocko@suse.com
Subject: [PATCH v2] mm, oom: enable rate-limiting controls for oom dumps
Date: Tue, 13 Oct 2020 13:01:23 +0200	[thread overview]
Message-ID: <20201013110123.30689-1-ricardo.canuelo@collabora.com> (raw)

Add two sysctl entries (vm.oom_dump_ratelimit and
vm.oom_dump_ratelimit_burst) to control the rate limiting interval and
burst, respectively, of the OOM killer output (oom_kill_process()).

These entries are disabled by default and can be enabled during kernel
configuration with CONFIG_DUMP_RATELIMIT. They take
DEFAULT_RATELIMIT_INTERVAL and DEFAULT_RATELIMIT_BURST as their default
values.

In some setups, the amount of output that the OOM killer generates when
it kills a process and dumps the list of tasks can be too
large. Unfortunately, the rate-limiting used for it uses the default
values for the rate limit interval and burst. This patch allows the user
to configure these values.

Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
---

I'm sending this v2 because I found a mistake in the first version: the
oom_dump_ratelimit sysctl parameter must use proc_dointvec_jiffies
instead of proc_dointvec so that the user can use it to specify the
number of seconds easily.

I also added the rationale to the commit log as Michal suggested and
moved the config option to mm/Kconfig.debug as suggested by Sergey:

    I personally like this patch. There are no universal ratelimit
    values, so having some sort of user configuration makes sense.

    One thing - I think that config option should be in mm/Kconfig.debug

but I'd like to keep the discussion open as there seem to be many
different opinions about this topic.

Cheers,
Ricardo

 include/linux/oom.h |  2 ++
 kernel/sysctl.c     | 16 ++++++++++++++++
 mm/Kconfig.debug    |  9 +++++++++
 mm/oom_kill.c       |  5 +++++
 4 files changed, 32 insertions(+)

diff --git a/include/linux/oom.h b/include/linux/oom.h
index 2db9a1432511..76c560a1a4c7 100644
--- a/include/linux/oom.h
+++ b/include/linux/oom.h
@@ -127,4 +127,6 @@ extern struct task_struct *find_lock_task_mm(struct task_struct *p);
 extern int sysctl_oom_dump_tasks;
 extern int sysctl_oom_kill_allocating_task;
 extern int sysctl_panic_on_oom;
+extern int sysctl_oom_dump_ratelimit;
+extern int sysctl_oom_dump_ratelimit_burst;
 #endif /* _INCLUDE_LINUX_OOM_H */
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index ce75c67572b9..dd51a7e26a54 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -2708,6 +2708,22 @@ static struct ctl_table vm_table[] = {
 		.mode		= 0644,
 		.proc_handler	= proc_dointvec,
 	},
+#ifdef CONFIG_OOM_DUMP_RATELIMIT
+	{
+		.procname	= "oom_dump_ratelimit",
+		.data		= &sysctl_oom_dump_ratelimit,
+		.maxlen		= sizeof(sysctl_oom_dump_ratelimit),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec_jiffies,
+	},
+	{
+		.procname	= "oom_dump_ratelimit_burst",
+		.data		= &sysctl_oom_dump_ratelimit_burst,
+		.maxlen		= sizeof(sysctl_oom_dump_ratelimit_burst),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec,
+	},
+#endif
 	{
 		.procname	= "overcommit_ratio",
 		.data		= &sysctl_overcommit_ratio,
diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug
index 864f129f1937..93207f26d57a 100644
--- a/mm/Kconfig.debug
+++ b/mm/Kconfig.debug
@@ -170,3 +170,12 @@ config PTDUMP_DEBUGFS
 	  kernel.
 
 	  If in doubt, say N.
+
+config OOM_DUMP_RATELIMIT
+	bool "Enable rate limiting for OOM dumps"
+	default n
+	help
+	  Say Y here to enable the configuration of the rate limiting of
+	  OOM task dumps to the console through sysctl entries
+	  vm.oom_dump_ratelimit (rate limit interval) and
+	  vm.oom_dump_ratelimit_burst (rate limit burst).
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 8b84661a6410..2b3fa826a172 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -54,6 +54,8 @@
 int sysctl_panic_on_oom;
 int sysctl_oom_kill_allocating_task;
 int sysctl_oom_dump_tasks = 1;
+int sysctl_oom_dump_ratelimit = DEFAULT_RATELIMIT_INTERVAL;
+int sysctl_oom_dump_ratelimit_burst = DEFAULT_RATELIMIT_BURST;
 
 /*
  * Serializes oom killer invocations (out_of_memory()) from all contexts to
@@ -959,6 +961,9 @@ static void oom_kill_process(struct oom_control *oc, const char *message)
 	static DEFINE_RATELIMIT_STATE(oom_rs, DEFAULT_RATELIMIT_INTERVAL,
 					      DEFAULT_RATELIMIT_BURST);
 
+	oom_rs.interval = sysctl_oom_dump_ratelimit;
+	oom_rs.burst = sysctl_oom_dump_ratelimit_burst;
+
 	/*
 	 * If the task is already exiting, don't alarm the sysadmin or kill
 	 * its children or threads, just give it access to memory reserves
-- 
2.18.0



             reply	other threads:[~2020-10-13 11:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-13 11:01 Ricardo Cañuelo [this message]
2020-10-13 11:18 ` 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=20201013110123.30689-1-ricardo.canuelo@collabora.com \
    --to=ricardo.canuelo@collabora.com \
    --cc=akpm@linux-foundation.org \
    --cc=guro@fb.com \
    --cc=hch@lst.de \
    --cc=keescook@chromium.org \
    --cc=kernel@collabora.com \
    --cc=linux-mm@kvack.org \
    --cc=mcgrof@kernel.org \
    --cc=mhocko@suse.com \
    --cc=pmladek@suse.com \
    --cc=rientjes@google.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=yzaikin@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox