Messages in this thread | | | Date | Thu, 22 Jan 2009 00:43:38 -0800 (PST) | From | David Rientjes <> | Subject | Re: [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.
| |