[Devel] Re: [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.
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
More information about the Devel
mailing list