Messages in this thread | | | From | Nikanth Karthikesan <> | Subject | Re: [RFC] [PATCH] Cgroup based OOM killer controller | Date | Thu, 22 Jan 2009 10:42:50 +0530 |
| |
On Thursday 22 January 2009 08:23:24 KAMEZAWA Hiroyuki wrote: > On Wed, 21 Jan 2009 12:49:50 -0800 (PST) > > David Rientjes <rientjes@google.com> wrote: > > On Wed, 21 Jan 2009, Nikanth Karthikesan wrote: > > > This is a container group based approach to override the oom killer > > > selection without losing all the benefits of the current oom killer > > > heuristics and oom_adj interface. > > > > > > It adds a tunable oom.victim to the oom cgroup. The oom killer will > > > kill the process using the usual badness value but only within the > > > cgroup with the maximum value for oom.victim before killing any process > > > from a cgroup with a lesser oom.victim number. Oom killing could be > > > disabled by setting oom.victim=0. > > > > This doesn't help in memcg or cpuset constrained oom conditions, which > > still go through select_bad_process(). > > > > If the oom.victim value is high for a specific cgroup and a memory > > controller oom occurs in a disjoint cgroup, for example, it's possible to > > needlessly kill tasks. Obviously that is up to the administrator to > > configure, but may not be his or her desire for system-wide oom > > conditions. > > Hmm...after this patch, select_bad_process's filter to select process will > be > > == > 1. ->mm is NULL ? => don't select this > 2. is init task ? => don't select this > 3. is under specified memcg ? => don't select this > 4. marked as MEMDIE ? => return -1. > 5. PF_EXITING? => select this. > 6. OOM_DISABLE ? => don't select this > points = badness(p, uptime.tv_sec); > 7. adjust point & select logic depends on OOM cgroup > == > > Not looks good ;) >
Yes, we do throw away a lot of needless work done. But this is how we already do and this is not a regression. But this could be used to improve the OOM killer's speed.
> > It may be preferred to kill tasks in a specific cgroup first when the > > entire system is out of memory or kill tasks within a cgroup attached to > > a memory controller when it is oom. > > I agree here. > > Above filter logic should be > == > current_victim_level++; > 1. p is under oom cgroup of victim_level > current_victim_level => don't > select this. 2. ->mm is NULL ? => don't select this > 3. is init task ? => don't select this > 4. is under specified memcg ? => don't select this > 5. marked as MEMDIE ? => return -1. > 6. PF_EXITING? => select this. > 7. OOM_DISABLE ? => don't select this > points = badness(p, uptime.tv_sec) > == > But this will be too slow. > > I think do_each_thread() in select_bad_process() should be replaced with > a routine like this, finally. > == > for_each_oom_cgroup_in_victim_value_order() { > for_each_threads_in_oom_cgroup(oom) { > select one bad thread. > } > if (selected_one_is_enough_bad ?) > return selected_one; > } > == >
Yes.
> And this can be a help for "spped up OOM killer" problem. >
Yes.
Thanks Nikanth
| |