Re: [patch -mm 01/18] oom: filter tasks not sharing the same cpuset

[David Rientjes <rientjes@google.com>]

On Tue, 8 Jun 2010, Andrew Morton wrote:

> > Tasks that do not share the same set of allowed nodes with the task that
> > triggered the oom should not be considered as candidates for oom kill.
> > 
> > Tasks in other cpusets with a disjoint set of mems would be unfairly
> > penalized otherwise because of oom conditions elsewhere; an extreme
> > example could unfairly kill all other applications on the system if a
> > single task in a user's cpuset sets itself to OOM_DISABLE and then uses
> > more memory than allowed.
> 
> OK, so Nick's change didn't anticipate things being set to OOM_DISABLE?
> 

I wrote out a more elaborate rebuttal to this in your reply to my latest 
patchset, but not strictly eliminating these tasks from consideration 
unfairly penalizes tasks in other cpusets simply because their big, 
there's no way to understand the scale of other cpusets compared to 
current's with a single divide in the heuristic (in this case, divide by 
8), and there's no guarantee that killing such a task would free any 
memory which would have two results: (i) we need to reinvoke the oom 
killer to kill yet another task, and (ii) we've now unnecessarily killed a 
task simply because it was large and probably lost a substantial amount of 
work.

> OOM_DISABLE seems pretty dangerous really - allows malicious
> unprivileged users to go homicidal?
> 

OOM_DISABLE doesn't get set without CAP_SYS_RESOURCE, you need that 
capability to decrease an oom_adj value.  So my changelog could probably 
benefit from s/user/job/.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>