[Devel] Re: [RFC] [PATCH] Cgroup based OOM killer controller

[David Rientjes]

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.
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers