lkml.org 
[lkml]   [2009]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] [PATCH] Cgroup based OOM killer controller
On Thu, 22 Jan 2009, Nikanth Karthikesan wrote:

> No, this is not specific to memcg or cpuset cases alone. The same needless
> kills will take place even without memcg or cpuset when an administrator
> specifies a light memory consumer to be killed before a heavy memory user. But
> it is up to the administrator to use it wisely.

You can't specify different behavior for an oom cgroup depending on what
type of oom it is, which is the problem with this proposal.

For example, if your task triggers an oom as the result of its exclusive
cpuset placement, the oom killer should prefer to kill a task within that
cpuset to allow for future memory freeing.

So, with your proposal, an administrator can specify the oom priority of
an entire aggregate of tasks but the behavior may not be desired for a
cpuset-constrained oom, while it may be perfectly legitimate for a global
unconstrained oom.

I can specify a higher oom priority for a cpuset because its jobs are less
critical and I would prefer it gets killed in a system-wide oom, but any
other cpuset that ooms will needlessly kill these tasks when there is no
benefit.

> We also provide a panic_on_oom
> option that an administrator could use, not just to kill few more tasks but
> all tasks in the system ;)
>

panic_on_oom allows you to specify whether you want to panic on any oom or
on global non-constrained ooms, as well. When the sysctl is not set to 2,
it is a no-op in a cpuset, mempolicy, or memcg oom condition.


\
 
 \ /
  Last update: 2009-01-22 09:49    [W:0.129 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site