Messages in this thread | | | Date | Wed, 1 Dec 2010 13:01:29 +0800 | From | Américo Wang <> | Subject | Re: [PATCH v4] sched: automated per session task groups |
| |
On Tue, Nov 30, 2010 at 02:36:22PM -0500, Vivek Goyal wrote: > >So again, user will think that task is in cgroup test1 and is being >controlled by the respective weight but that's not the case. > >Even if we prevent autogroup task from being visible in cpu controller >root group, then comes the question what happens if cpu and some other >controller is comounted. Say cpuset. Now in that case will task be >visible in root group task file and can one operate on that. Now showing >up there does not make much sense as task should still be controllable >by other controllers and its policies. > >So yes, creating a /proc/<pid>/autogroup is dirt cheap and makes the life >easier in terms of implementation of this patch and it should work well. >But it is also a new user interface which does not sound too extensible and >does not seem to cooperate well with cgroup interface. > >It also introduces this new notion of niceness for task groups which is sort >of equivalent to cpu.shares in cpu controller. First of all why should we >not stick to shares notion even for autogroup. Even if we introduce the notion >of niceness for groups, IMHO, it should be through cgroup interface instead of >group niceness for autogroup and shares/weights for cgroup despite the >fact that in the background they do similar things. >
Hmm, maybe we can make AUTO_GROUP depend on !CGROUPS?
It seems that autogroup only uses 'struct task_group', no other cgroup things, so I think that is reasonable and doable.
| |