From: Michal Hocko <mhocko@kernel.org>
To: linux-mm@kvack.org
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
Roman Gushchin <guro@fb.com>,
Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@suse.com>
Subject: [RFC PATCH 2/3] mm, oom: keep retrying the oom_reap operation as long as there is substantial memory left
Date: Mon, 10 Sep 2018 14:55:12 +0200 [thread overview]
Message-ID: <20180910125513.311-3-mhocko@kernel.org> (raw)
In-Reply-To: <20180910125513.311-1-mhocko@kernel.org>
From: Michal Hocko <mhocko@suse.com>
oom_reaper is not able to reap all types of memory. E.g. mlocked
mappings or page tables. In some cases this might be a lot of memory
and we do rely on exit_mmap to release that memory. Yet we cannot rely
on exit_mmap to set MMF_OOM_SKIP right now because there are several
places when sleeping locks are taken.
This patch adds a simple heuristic to check for the amount of memory
the mm is sitting on after oom_reaper is done with it. If this is still
few megabytes (this is a subject for further tunning based on real world
usecases) then simply keep retrying oom_reap_task_mm.
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
mm/oom_kill.c | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index f10aa5360616..049e67dc039b 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -189,6 +189,16 @@ static bool is_dump_unreclaim_slabs(void)
return (global_node_page_state(NR_SLAB_UNRECLAIMABLE) > nr_lru);
}
+/*
+ * Rough memory consumption of the given mm which should be theoretically freed
+ * when the mm is removed.
+ */
+static unsigned long oom_badness_pages(struct mm_struct *mm)
+{
+ return get_mm_rss(mm) + get_mm_counter(mm, MM_SWAPENTS) +
+ mm_pgtables_bytes(mm) / PAGE_SIZE;
+}
+
/**
* oom_badness - heuristic function to determine which candidate task to kill
* @p: task struct of which task we should calculate
@@ -230,8 +240,7 @@ unsigned long oom_badness(struct task_struct *p, struct mem_cgroup *memcg,
* The baseline for the badness score is the proportion of RAM that each
* task's rss, pagetable and swap space use.
*/
- points = get_mm_rss(p->mm) + get_mm_counter(p->mm, MM_SWAPENTS) +
- mm_pgtables_bytes(p->mm) / PAGE_SIZE;
+ points = oom_badness_pages(p->mm);
task_unlock(p);
/* Normalize to oom_score_adj units */
@@ -532,6 +541,16 @@ bool __oom_reap_task_mm(struct mm_struct *mm)
}
}
+ /*
+ * If we still sit on a noticeable amount of memory even after successfully
+ * reaping the address space then keep retrying until exit_mmap makes some
+ * further progress.
+ * TODO: add a flag for a stage when the exit path doesn't block anymore
+ * and hand over MMF_OOM_SKIP handling there in that case
+ */
+ if (ret && oom_badness_pages(mm) > 1024)
+ ret = false;
+
return ret;
}
--
2.18.0
next prev parent reply other threads:[~2018-09-10 12:55 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-08 4:54 [PATCH v2] mm, oom: Fix unnecessary killing of additional processes Tetsuo Handa
2018-09-10 9:54 ` Michal Hocko
2018-09-10 11:27 ` Tetsuo Handa
2018-09-10 11:40 ` Michal Hocko
2018-09-10 12:52 ` Tetsuo Handa
2018-09-10 12:55 ` [RFC PATCH 0/3] rework mmap-exit vs. oom_reaper handover Michal Hocko
2018-09-10 12:55 ` [RFC PATCH 1/3] mm, oom: rework mmap_exit vs. oom_reaper synchronization Michal Hocko
2018-09-10 12:55 ` Michal Hocko [this message]
2018-09-10 12:55 ` [RFC PATCH 3/3] mm, oom: hand over MMF_OOM_SKIP to exit path if it is guranteed to finish Michal Hocko
2018-09-10 14:59 ` [RFC PATCH 0/3] rework mmap-exit vs. oom_reaper handover Tetsuo Handa
2018-09-10 15:11 ` Michal Hocko
2018-09-10 15:40 ` Tetsuo Handa
2018-09-10 16:44 ` Michal Hocko
2018-09-12 3:06 ` Tetsuo Handa
2018-09-12 7:18 ` Michal Hocko
2018-09-12 7:58 ` Tetsuo Handa
2018-09-12 8:17 ` Michal Hocko
2018-09-12 10:59 ` Tetsuo Handa
2018-09-12 11:22 ` Michal Hocko
2018-09-11 14:01 ` Tetsuo Handa
2018-09-12 7:50 ` Michal Hocko
2018-09-12 13:42 ` Michal Hocko
2018-09-13 2:44 ` Tetsuo Handa
2018-09-13 9:09 ` Michal Hocko
2018-09-13 11:20 ` Tetsuo Handa
2018-09-13 11:35 ` Michal Hocko
2018-09-13 11:53 ` Tetsuo Handa
2018-09-13 13:40 ` Michal Hocko
2018-09-14 13:54 ` Tetsuo Handa
2018-09-14 14:14 ` Michal Hocko
2018-09-14 17:07 ` 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=20180910125513.311-3-mhocko@kernel.org \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=guro@fb.com \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
/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.