Messages in this thread | | | From | Nikanth Karthikesan <> | Subject | Re: [RFC] [PATCH] Cgroup based OOM killer controller | Date | Thu, 22 Jan 2009 15:40:07 +0530 |
| |
On Thursday 22 January 2009 15:09:28 David Rientjes wrote: > 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.
Thanks for the clear explanation. Cpuset does it by reducing the badness to 1/8th for tasks. So using oom-controller could kill some innocent processes on some other cpuset!
But it is possible to have the same effect with oom_adj, having oom_adj=4 for a task on a diff cpuset will do the same(assuming they have similar badness).
I think cpusets preference could be improved, not to depend on badness, with something similar to what memcg does. With or without adding overhead of tracking processes that has memory from a node.
Thanks Nikanth
| |