[lkml]   [2013]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 2/2] mm, memcg: add memory.oom_control notification for system oom
On Mon, 18 Nov 2013, Michal Hocko wrote:

> > A subset of applications that wait on memory.oom_control don't disable
> > the oom killer for that memcg and simply log or cleanup after the kernel
> > oom killer kills a process to free memory.
> >
> > We need the ability to do this for system oom conditions as well, i.e.
> > when the system is depleted of all memory and must kill a process. For
> > convenience, this can use memcg since oom notifiers are already present.
> Using the memcg interface for "read-only" interface without any plan for
> the "write" is only halfway solution. We want to handle global OOM in a
> more user defined ways but we have to agree on the proper interface
> first. I do not want to end up with something half baked with memcg and
> a different interface to do the real thing just because memcg turns out
> to be unsuitable.

This patch isn't really a halfway solution, you can still determine if the
open(O_WRONLY) succeeds or not to determine if that feature has been
implemented. I'm concerned about disabling the oom killer entirely for
system oom conditions, though, so I didn't implement it to be writable. I
don't think we should be doing anything special in terms of "write"
behavior for the root memcg memory.oom_control, so I'd argue against doing
anything other than disabling the oom killer. That's scary.

 \ /
  Last update: 2013-11-19 02:41    [W:4.647 / U:5.944 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site