[lkml]   [2009]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] [PATCH] Cgroup based OOM killer controller
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

> 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.

 \ /
  Last update: 2009-01-27 21:33    [from the cache]
©2003-2011 Jasper Spaans