[RFC] [PATCH] Cgroup based OOM killer controller
David Rientjes
rientjes at google.com
Tue Jan 27 12:29:20 PST 2009
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.
More information about the Containers
mailing list