From: David Rientjes <rientjes@google.com>
To: Andrew Morton <akpm@linux-foundation.org>,
Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Michal Hocko <mhocko@suse.cz>,
Johannes Weiner <hannes@cmpxchg.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
cgroups@vger.kernel.org
Subject: Re: [patch] mm, memcg: add oom killer delay
Date: Wed, 19 Jun 2013 14:30:59 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.02.1306191429340.13015@chino.kir.corp.google.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1306140254590.8780@chino.kir.corp.google.com>
On Fri, 14 Jun 2013, David Rientjes wrote:
> Even with all of the above (which is not actually that invasive of a
> patch), I still think we need memory.oom_delay_millisecs. I probably made
> a mistake in describing what that is addressing if it seems like it's
> trying to address any of the above.
>
> If a userspace oom handler fails to respond even with access to those
> "memcg reserves", the kernel needs to kill within that memcg. Do we do
> that above a set time period (this patch) or when the reserves are
> completely exhausted? That's debatable, but if we are to allow it for
> global oom conditions as well then my opinion was to make it as safe as
> possible; today, we can't disable the global oom killer from userspace and
> I don't think we should ever allow it to be disabled. I think we should
> allow userspace a reasonable amount of time to respond and then kill if it
> is exceeded.
>
> For the global oom case, we want to have a priority-based memcg selection.
> Select the lowest priority top-level memcg and kill within it. If it has
> an oom notifier, send it a signal to kill something. If it fails to
> react, kill something after memory.oom_delay_millisecs has elapsed. If
> there isn't a userspace oom notifier, kill something within that lowest
> priority memcg.
>
> The bottomline with my approach is that I don't believe there is ever a
> reason for an oom memcg to remain oom indefinitely. That's why I hate
> memory.oom_control == 1 and I think for the global notification it would
> be deemed a nonstarter since you couldn't even login to the machine.
>
What's the status of this patch? I'd love to be able to introduce memcg
reserves so that userspace oom notifications can actually work, but we
still require a failsafe in the kernel if those reserves are depleted or
userspace cannot respond.
--
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:[~2013-06-19 21:31 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-30 1:18 David Rientjes
2013-05-30 15:07 ` Michal Hocko
2013-05-30 20:47 ` David Rientjes
2013-05-31 8:10 ` Michal Hocko
2013-05-31 10:22 ` David Rientjes
2013-05-31 11:02 ` Michal Hocko
2013-05-31 11:21 ` Michal Hocko
2013-05-31 19:29 ` David Rientjes
2013-06-01 6:11 ` Johannes Weiner
2013-06-01 10:29 ` Michal Hocko
2013-06-01 15:15 ` Johannes Weiner
2013-06-03 15:34 ` Michal Hocko
2013-06-03 16:48 ` Johannes Weiner
2013-06-03 18:03 ` Michal Hocko
2013-06-03 18:30 ` Johannes Weiner
2013-06-03 21:33 ` KOSAKI Motohiro
2013-06-04 9:17 ` Michal Hocko
2013-06-04 18:48 ` Johannes Weiner
2013-06-04 19:27 ` Michal Hocko
2013-06-05 13:49 ` Michal Hocko
2013-06-03 16:31 ` Michal Hocko
2013-06-03 16:51 ` Johannes Weiner
2013-06-01 10:20 ` Michal Hocko
2013-06-03 18:18 ` David Rientjes
2013-06-03 18:54 ` Johannes Weiner
2013-06-03 19:09 ` David Rientjes
2013-06-03 21:43 ` Johannes Weiner
2013-06-03 19:31 ` Michal Hocko
2013-06-03 21:17 ` David Rientjes
2013-06-04 9:55 ` Michal Hocko
2013-06-05 6:40 ` David Rientjes
2013-06-05 9:39 ` Michal Hocko
2013-06-06 0:09 ` David Rientjes
2013-06-10 14:23 ` Michal Hocko
2013-06-11 20:33 ` David Rientjes
2013-06-12 20:23 ` Michal Hocko
2013-06-12 21:27 ` David Rientjes
2013-06-13 15:16 ` Michal Hocko
2013-06-13 22:25 ` David Rientjes
2013-06-14 0:56 ` Kamezawa Hiroyuki
2013-06-14 10:12 ` David Rientjes
2013-06-19 21:30 ` David Rientjes [this message]
2013-06-25 1:39 ` Kamezawa Hiroyuki
2013-06-26 23:18 ` David Rientjes
2013-07-10 11:23 ` Michal Hocko
2013-05-31 21:46 ` Andrew Morton
2013-06-03 18:00 ` 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=alpine.DEB.2.02.1306191429340.13015@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--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