From: Michal Hocko <mhocko@kernel.org>
To: David Rientjes <rientjes@google.com>
Cc: linux-mm@kvack.org,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC 1/3] oom, sysrq: Skip over oom victims and killed tasks
Date: Wed, 20 Jan 2016 10:49:38 +0100 [thread overview]
Message-ID: <20160120094938.GB14187@dhcp22.suse.cz> (raw)
In-Reply-To: <alpine.DEB.2.10.1601191454160.7346@chino.kir.corp.google.com>
On Tue 19-01-16 14:57:33, David Rientjes wrote:
> On Fri, 15 Jan 2016, Michal Hocko wrote:
>
> > > I think it's time to kill sysrq+F and I'll send those two patches
> > > unless there is a usecase I'm not aware of.
> >
> > I have described one in the part you haven't quoted here. Let me repeat:
> > : Your system might be trashing to the point you are not able to log in
> > : and resolve the situation in a reasonable time yet you are still not
> > : OOM. sysrq+f is your only choice then.
> >
> > Could you clarify why it is better to ditch a potentially usefull
> > emergency tool rather than to make it work reliably and predictably?
>
> I'm concerned about your usecase where the kernel requires admin
> intervention to resolve such an issue and there is nothing in the VM we
> can do to fix it.
>
> If you have a specific test that demonstrates when your usecase is needed,
> please provide it so we can address the issue that it triggers.
No, I do not have a specific load in mind. But let's be realistic. There
will _always_ be corner cases where the VM cannot react properly or in a
timely fashion.
> I'd prefer to fix the issue in the VM rather than require human
> intervention, especially when we try to keep a very large number of
> machines running in our datacenters.
It is always preferable to resolve the mm related issue automagically,
of course. We should strive for robustness as much as possible but that
doesn't mean we should get the only emergency tool out of administrator
hands.
To be honest I really fail to understand your line of argumentation
here. Just that you think that sysrq+f might be not helpful in large
datacenters which you seem to care about, doesn't mean that it is not
helpful in other setups.
Removing the functionality is out of question IMHO so can we please
start discussing how to make it more predictable please?
--
Michal Hocko
SUSE Labs
--
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:[~2016-01-20 9:49 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-12 21:00 [RFC 0/3] oom: few enahancements Michal Hocko
2016-01-12 21:00 ` [RFC 1/3] oom, sysrq: Skip over oom victims and killed tasks Michal Hocko
2016-01-13 0:41 ` David Rientjes
2016-01-13 9:30 ` Michal Hocko
2016-01-14 0:38 ` David Rientjes
2016-01-14 11:00 ` Michal Hocko
2016-01-14 21:51 ` David Rientjes
2016-01-15 10:12 ` Michal Hocko
2016-01-15 15:37 ` One Thousand Gnomes
2016-01-19 23:01 ` David Rientjes
2016-01-19 22:57 ` David Rientjes
2016-01-20 9:49 ` Michal Hocko [this message]
2016-01-21 0:01 ` David Rientjes
2016-01-21 9:15 ` Michal Hocko
2016-01-12 21:00 ` [RFC 2/3] oom: Do not sacrifice already OOM killed children Michal Hocko
2016-01-13 0:45 ` David Rientjes
2016-01-13 9:36 ` Michal Hocko
2016-01-14 0:42 ` David Rientjes
2016-01-12 21:00 ` [RFC 3/3] oom: Do not try to sacrifice small children Michal Hocko
2016-01-13 0:51 ` David Rientjes
2016-01-13 9:40 ` Michal Hocko
2016-01-14 0:43 ` David Rientjes
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=20160120094938.GB14187@dhcp22.suse.cz \
--to=mhocko@kernel.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