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

[David Rientjes]

On Tue, 27 Jan 2009, Nikanth Karthikesan wrote:

> > That's certainly idealistic, but cannot be done in an inexpensive way that
> > would scale with the large systems that clients of cpusets typically use.
> 
> If we kill only the tasks for which cpuset_mems_allowed_intersects() is true 
> on the first pass and even then if we do not get out of oom, we could go over 
> again with this expensive check.

The oom killer has no memory of previous kills, so it's not possible to 
determine if there've been a series of recent needless ones.  Subsequent 
oom conditions should still check for intersection and, since it's only a 
heuristic, a large memory-hogging task will eventually be killed if there 
are no tasks remaining with such an intersection.

I don't know how you're planning on mapping large memory allocations on 
nodes of interest back to specific tasks, however.  Do you have a 
proposal?

> Using this scheme, could kill more no of 
> tasks than required, if a task with lots of memory has moved to a different 
> cpuset.

That's rare, since cpusets are used for NUMA optimizations and a set of 
cpus has a static affinity to certain memory.  It could happen if a 
cpuset's set of allowable nodes is made to be smaller, but that seems like 
it would trigger the oom in the first place and would encourage killing 
tasks with an intersection.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/