On Sun, 6 Jun 2010 15:34:25 -0700 (PDT) David Rientjes <rientjes@xxxxxxxxxx> 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. > > Killing tasks outside of current's cpuset rarely would free memory for > current anyway. To use a sane heuristic, we must ensure that killing a > task would likely free memory for current and avoid needlessly killing > others at all costs just because their potential memory freeing is > unknown. It is better to kill current than another task needlessly. This is all a bit arbitrary, isn't it? The key word here is "rarely". If indeed this task had allocated gobs of memory from `current's nodes and then sneakily switched nodes, this will be a big regression! So.. It's not completely clear to me how we justify this decision. Are we erring too far on the side of keep-tasks-running? Is failing to clear the oom a lot bigger problem than killing an innocent task? I think so. In which case we should err towards slaughtering the innocent? -- 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>