lkml.org 
[lkml]   [2013]   [Dec]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: user defined OOM policies
On Thu, 28 Nov 2013, Michal Hocko wrote:

> > Agreed, and I think the big downside of doing it with the loadable module
> > suggestion is that you can't implement such a wide variety of different
> > policies in modules. Each of our users who own a memcg tree on our
> > systems may want to have their own policy and they can't load a module at
> > runtime or ship with the kernel.
>
> But those users care about their local (memcg) OOM, don't they? So they
> do not need any module and all they want is to get a notification.

Sure, but I think the question is more of the benefit of doing it in the
kernel as opposed to userspace. If we implement the necessary mechanisms
that allow userspace to reliably handle these situations, I don't see much
of a benefit to modules other than for separating code amongst multiple
files in the source. I don't think we want to ship multiple different oom
policies because then userspace that cares about it has to figure out
what's in effect and what it can do with what's available. I'd argue that
a the key functionality that I've already described (system oom
notification, memcg reserves, timeout) allow for any policy to be defined
reliably in userspace.


\
 
 \ /
  Last update: 2013-12-03 00:21    [W:0.836 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site