Messages in this thread | | | Date | Fri, 23 Jan 2009 12:44:59 -0800 (PST) | From | David Rientjes <> | Subject | Re: [RFC] [PATCH] Cgroup based OOM killer controller |
| |
On Fri, 23 Jan 2009, Nikanth Karthikesan wrote:
> In other instances, It can actually also kill some innocent tasks unless the > administrator tunes oom_adj, say something like kvm which would have a huge > memory accounted, but might be from a different node altogether. Killing a > single vm is killing all of the processes in that OS ;) Don't you think this > has to be fixed^Wimproved? >
As previously stated, I think the heuristic to penalize tasks for not having an intersection with the set of allowable nodes of the oom triggering task could be made slightly more severe. That's irrelevant to your patch, though.
> > That's my objection to the proposal: it doesn't behave appropriately for > > both global unconstrained ooms and cpuset-constrained ooms at the same > > time. > > > > So you are against specifying order when it is a cpuset-constrained oom. Here > is a revised version of the patch which adds oom.cpuset_constraint, when set > to 1 would disable the ordering imposed by this controller for cpuset > constrained ooms! Will this work for you? >
No, I don't think it's appropriate to add special exemptions for specific subsystems to what should be a generic cgroup. I think it is much more powerful to defer these decisions to userspace so each cgroup can attach its own handler and implement the necessary decision-making that the kernel could never perfectly handle for all possible workloads.
It is trivial to implement the equivalent of this particular change as a userspace handler to SIGKILL all tasks in a specific cgroup when the cgroup oom handler is woken up at the time of oom. Additionally, it could also respond in other ways such as adding a node to a cpuset, killing a less important cgroup, elevate a memory controller limit, send a signal to your application to release memory, etc.
We also talked about a cgroup /dev/mem_notify device file that you can poll() and learn of low memory situations so that appropriate action can be taken even in lowmem situations as opposed to simply oom conditions.
These types of policy decisions belong in userspace.
| |