On Thu, 22 Jan 2009, Nikanth Karthikesan wrote: > > You can't specify different behavior for an oom cgroup depending on what > > type of oom it is, which is the problem with this proposal. > > > > No. This does not disable any such special selection criteria which is used > without this controller. > I didn't say it disabled it; the cpuset preference is actually implemented in the badness() score and not specifically excluded in select_bad_process(). That's because it's quite possible that a task has allocated memory in a cpuset and then either moved to a separate cpuset or had it's mems_allowed changed. Please try it and you'll see. Create two cpusets, cpuset A and cpuset B. Elevate cpuset A's oom.victim value and then trigger an oom in cpuset B. Your patch will cause a task from cpuset A to be killed for a cpuset B triggered oom which, more often than not, will not lead to future memory freeing. It's quite possible that cpuset A would be preferred to be killed in a global unconstrained oom condition, however. That's the only reason why one would elevate its oom.victim score to begin with. But it doesn't work for cpuset-constrained ooms. It's not going to help if it I explain it further and you don't try it out on your own. Thanks. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers