Messages in this thread | | | From | Nikanth Karthikesan <> | Subject | Re: [RFC] [PATCH] Cgroup based OOM killer controller | Date | Thu, 22 Jan 2009 11:42:00 +0530 |
| |
On Thursday 22 January 2009 11:09:45 Arve Hjønnevåg wrote: > On Wed, Jan 21, 2009 at 9:13 PM, Nikanth Karthikesan <knikanth@suse.de> wrote: > > To use oom_adj effectively one should continuously monitor oom_score of > > all the processes, which is a complex moving target and keep on adjusting > > the oom_adj of many tasks which still cannot guarantee the order. This > > controller is deterministic and hence easier to use. > > Why not add an option to make oom_adj ensure strict ordering instead?
This could be done in 2 ways. 1. Make oom_adj itself strict.(based on some other parameter?) - Adds to confusion whether the current oom_adj is a strict value or the usual suggestion. - It would disable the oom_adj suggestion which could have been used till now. - It is a public interface, and changing that might break some one's script.
2. Add addtional parameter, say /proc/<pid>/oom_order - Not easy to use. - Say I had assigned the oom.victim to a task and it had forked a lot. Now to change the value for all the tasks it is easier with cgroups. - Some optimization that Kame specified earlier would be harder to achieve.
Basically oom-controller implements option 2, using cgroups which can be thought of as a modern interface for proc. Also it could be used along with other cgroup controllers like the group scheduler. Say you have 2 groups of tasks, clubed as entertainment and science, you could use the group scheduler to give more CPU bandwidth to science and instruct oom-controller to kill entertainment tasks in case of OOM situation.
Thanks Nikanth
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |