From: Michal Hocko <mhocko@kernel.org>
To: David Rientjes <rientjes@google.com>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm,oom: Bring OOM notifier callbacks to outside of OOM killer.
Date: Thu, 21 Jun 2018 09:31:42 +0200 [thread overview]
Message-ID: <20180621073142.GA10465@dhcp22.suse.cz> (raw)
In-Reply-To: <alpine.DEB.2.21.1806201528490.16984@chino.kir.corp.google.com>
On Wed 20-06-18 15:36:45, David Rientjes wrote:
[...]
> That makes me think that "oom_notify_list" isn't very intuitive: it can
> free memory as a last step prior to oom kill. OOM notify, to me, sounds
> like its only notifying some callbacks about the condition. Maybe
> oom_reclaim_list and then rename this to oom_reclaim_pages()?
Yes agreed and that is the reason I keep saying we want to get rid of
this yet-another-reclaim mechanism. We already have shrinkers which are
the main source of non-lru pages reclaim. Why do we even need
oom_reclaim_pages? What is fundamentally different here? Sure those
pages should be reclaimed as the last resort but we already do have
priority for slab shrinking so we know that the system is struggling
when reaching the lowest priority. Isn't that enough to express the need
for current oom notifier implementations?
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2018-06-21 7:31 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-20 11:20 [PATCH] mm,oom: Bring OOM notifier callbacks to outside of OOM killer Tetsuo Handa
2018-06-20 11:55 ` Michal Hocko
2018-06-20 12:21 ` Tetsuo Handa
2018-06-20 13:07 ` Michal Hocko
2018-06-25 13:03 ` peter enderborg
2018-06-25 13:07 ` Michal Hocko
2018-06-25 14:02 ` peter enderborg
2018-06-25 14:04 ` peter enderborg
2018-06-25 14:12 ` Michal Hocko
2018-06-20 22:36 ` David Rientjes
2018-06-21 7:31 ` Michal Hocko [this message]
2018-06-21 11:27 ` Tetsuo Handa
2018-06-21 12:05 ` Michal Hocko
2018-06-26 17:03 ` Paul E. McKenney
2018-06-26 20:10 ` Tetsuo Handa
2018-06-26 23:50 ` Paul E. McKenney
2018-06-27 10:52 ` Tetsuo Handa
2018-06-27 14:28 ` Paul E. McKenney
2018-06-27 7:22 ` Michal Hocko
2018-06-27 14:31 ` Paul E. McKenney
2018-06-28 11:39 ` Michal Hocko
2018-06-28 21:31 ` Paul E. McKenney
2018-06-29 9:04 ` Michal Hocko
2018-06-29 12:52 ` Paul E. McKenney
2018-06-29 13:26 ` Michal Hocko
2018-06-30 17:05 ` Paul E. McKenney
2018-07-02 12:00 ` Michal Hocko
2018-07-02 21:37 ` Paul E. McKenney
2018-07-03 7:24 ` Michal Hocko
2018-07-03 16:01 ` Paul E. McKenney
2018-07-06 5:39 ` Michal Hocko
2018-07-06 12:22 ` Paul E. McKenney
2018-06-29 14:35 ` Tetsuo Handa
2018-06-30 17:19 ` Paul E. McKenney
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=20180621073142.GA10465@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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 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).