> On Tue, 8 Jun 2010 16:54:31 -0700 (PDT) > David Rientjes <rientjes@xxxxxxxxxx> wrote: > > > On Tue, 8 Jun 2010, Andrew Morton wrote: > > > > > And I wonder if David has observed some problem which the 2010 change > > > fixes! > > > > > > > Yes, as explained in my changelog. I'll paste it: > > > > 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? > > OOM_DISABLE seems pretty dangerous really - allows malicious > unprivileged users to go homicidal? Just clarify. David's patch have following Pros/Cons. Pros - 1/8 badness was inaccurate and a bit unclear why 1/8. - Usually, almost processes don't change their cpuset mask in their life time. then, cpuset_mems_allowed_intersects() is so so good heuristic. Cons - But, they can change CPUSET mask. we can't assume cpuset_mems_allowed_intersects() return always correct memory usage. - The task may have mlocked page cache out of CPUSET mask. (probably they are using cpuset.memory_spread_page, perhaps) I don't think this is OOM_DISABLE related issue. I think just heuristic choice matter. Both approaches have corner case obviously. Then, I asked most typical workload concern and test result. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>