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

From: David Rientjes
Date: Fri Jan 23 2009 - 15:47:17 EST

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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at