From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, Michal Hocko <mhocko@suse.com>,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Subject: [PATCH 3/4] mm, oom: Wait for OOM victims even if oom_kill_allocating_task case.
Date: Wed, 22 May 2019 19:08:05 +0900 [thread overview]
Message-ID: <1558519686-16057-3-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <1558519686-16057-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp>
"mm, oom: Avoid potential RCU stall at dump_tasks()." changed to imply
oom_dump_tasks == 0 if oom_kill_allocating_task != 0. But since we can
expect the OOM reaper to reclaim memory quickly, and majority of latency
is not for_each_process() from select_bad_process() but printk() from
dump_header(), waiting for in-flight OOM victims until the OOM reaper
completes should generate preferable results (i.e. minimal number of
OOM victims).
As side effects of this patch, oom_kill_allocating_task != 0 no longer
implies oom_dump_tasks == 0, complicated conditions for whether to enter
oom_kill_allocating_task path are simplified, and a theoretical bug that
the OOM killer forever retries oom_kill_allocating_task path even after
the OOM reaper set MMF_OOM_SKIP is fixed.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
mm/oom_kill.c | 44 +++++++++++++++++++++++---------------------
1 file changed, 23 insertions(+), 21 deletions(-)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 00b594c..64e582e 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -367,19 +367,29 @@ static int oom_evaluate_task(struct task_struct *task, void *arg)
* Simple selection loop. We choose the process with the highest number of
* 'points'. In case scan was aborted, oc->chosen is set to -1.
*/
-static void select_bad_process(struct oom_control *oc)
+static const char *select_bad_process(struct oom_control *oc)
{
- if (is_memcg_oom(oc))
- mem_cgroup_scan_tasks(oc->memcg, oom_evaluate_task, oc);
- else {
- struct task_struct *p;
+ struct task_struct *p;
- rcu_read_lock();
- for_each_process(p)
- if (oom_evaluate_task(p, oc))
- break;
- rcu_read_unlock();
+ if (is_memcg_oom(oc)) {
+ mem_cgroup_scan_tasks(oc->memcg, oom_evaluate_task, oc);
+ return "Memory cgroup out of memory";
}
+ rcu_read_lock();
+ for_each_process(p)
+ if (oom_evaluate_task(p, oc))
+ break;
+ rcu_read_unlock();
+ if (sysctl_oom_kill_allocating_task && oc->chosen != (void *)-1UL) {
+ list_for_each_entry(p, &oom_candidate_list,
+ oom_candidate_list) {
+ if (!same_thread_group(p, current))
+ continue;
+ oc->chosen = current;
+ return "Out of memory (oom_kill_allocating_task)";
+ }
+ }
+ return "Out of memory";
}
/**
@@ -1021,6 +1031,7 @@ bool out_of_memory(struct oom_control *oc)
{
unsigned long freed = 0;
enum oom_constraint constraint = CONSTRAINT_NONE;
+ const char *message;
if (oom_killer_disabled)
return false;
@@ -1061,15 +1072,7 @@ bool out_of_memory(struct oom_control *oc)
oc->nodemask = NULL;
check_panic_on_oom(oc, constraint);
- if (!is_memcg_oom(oc) && sysctl_oom_kill_allocating_task &&
- current->mm && !oom_unkillable_task(current, NULL, oc->nodemask) &&
- current->signal->oom_score_adj != OOM_SCORE_ADJ_MIN) {
- oc->chosen = current;
- oom_kill_process(oc, "Out of memory (oom_kill_allocating_task)");
- return true;
- }
-
- select_bad_process(oc);
+ message = select_bad_process(oc);
/* Found nothing?!?! */
if (!oc->chosen) {
dump_header(oc, NULL);
@@ -1083,8 +1086,7 @@ bool out_of_memory(struct oom_control *oc)
panic("System is deadlocked on memory\n");
}
if (oc->chosen && oc->chosen != (void *)-1UL)
- oom_kill_process(oc, !is_memcg_oom(oc) ? "Out of memory" :
- "Memory cgroup out of memory");
+ oom_kill_process(oc, message);
while (!list_empty(&oom_candidate_list)) {
struct task_struct *p = list_first_entry(&oom_candidate_list,
struct task_struct,
--
1.8.3.1
next prev parent reply other threads:[~2019-05-22 10:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-22 10:08 [PATCH 1/4] mm, oom: Remove redundant OOM score normalization at select_bad_process() Tetsuo Handa
2019-05-22 10:08 ` [PATCH 2/4] mm, oom: Avoid potential RCU stall at dump_tasks() Tetsuo Handa
2019-05-22 10:08 ` Tetsuo Handa [this message]
2019-05-22 10:08 ` [PATCH 4/4] mm, oom: Respect oom_task_origin() even if oom_kill_allocating_task case Tetsuo Handa
2019-05-23 22:04 ` [PATCH 5/4] mm, oom: Deduplicate memcg candidates at select_bad_process() 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=1558519686-16057-3-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp \
--to=penguin-kernel@i-love.sakura.ne.jp \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.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;
as well as URLs for NNTP newsgroup(s).