From: David Rientjes <rientjes@google.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] oom: split out forced OOM killer
Date: Thu, 4 Jun 2015 15:59:09 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.10.1506041557070.16555@chino.kir.corp.google.com> (raw)
In-Reply-To: <1433235187-32673-1-git-send-email-mhocko@suse.cz>
On Tue, 2 Jun 2015, Michal Hocko wrote:
> OOM killer might be triggered externally via sysrq+f. This is supposed
> to kill a task no matter what e.g. a task is selected even though there
> is an OOM victim on the way to exit. This is a big hammer for an admin
> to help to resolve a memory short condition when the system is not able
> to cope with it on its own in a reasonable time frame (e.g. when the
> system is trashing or the OOM killer cannot make sufficient progress).
>
> The forced OOM killing is currently wired into out_of_memory()
> call which is kind of ugly because generic out_of_memory path
> has to deal with configuration settings and heuristics which
> are completely irrelevant to the forced OOM killer (e.g.
> sysctl_oom_kill_allocating_task or OOM killer prevention for already
> dying tasks). Some of those will not apply to sysrq because the handler
> runs from the worker context.
> check_panic_on_oom on the other hand will work and that is kind of
> unexpected because sysrq+f should be usable to kill a mem hog whether
> the global OOM policy is to panic or not.
> It also doesn't make much sense to panic the system when no task cannot
> be killed because admin has a separate sysrq for that purpose.
>
> Let's pull forced OOM killer code out into a separate function
> (force_out_of_memory) which is really trivial now. Also extract the core
> of oom_kill_process into __oom_kill_process which doesn't do any
> OOM prevention heuristics.
> As a bonus we can clearly state that this is a forced OOM killer in the
> OOM message which is helpful to distinguish it from the regular OOM
> killer.
>
I'm not sure what the benefit of this is, and it's adding more code.
Having multiple pathways and requirements, such as constrained_alloc(), to
oom kill a process isn't any clearer, in my opinion. It also isn't
intended to be optimized since the oom killer called from the page
allocator and from sysrq aren't fastpaths. To me, this seems like only a
source code level change and doesn't make anything more clear but rather
adds more code and obfuscates the entry path.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-06-04 22:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-02 8:53 Michal Hocko
2015-06-04 22:59 ` David Rientjes [this message]
2015-06-05 11:28 ` Austin S Hemmelgarn
2015-06-08 17:59 ` David Rientjes
2015-06-08 18:58 ` Austin S Hemmelgarn
2015-06-08 19:41 ` David Rientjes
2015-06-08 21:06 ` Michal Hocko
2015-06-08 23:06 ` David Rientjes
2015-06-09 9:36 ` Michal Hocko
2015-06-09 22:45 ` David Rientjes
2015-06-10 7:37 ` 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=alpine.DEB.2.10.1506041557070.16555@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
/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