Weekly Edition
Return to the Kernel page
| |||||||||||||
A proposed plan for control groups
After the late-February discussion on the
future of control groups, Tejun Heo has boiled down the comments and
come to some conclusions as to where he
would like to go with this subsystem. The first of these is that multiple
hierarchies are doomed in the long term:
At least to me, nobody seems to have strong enough justification
for orthogonal multiple hierarchies, so, yeah, unless something
else happens, I'm scheduling multiple hierarchy support for the
chopping block. This is a long term thing (think years), so no
need to panic right now and as is life plans may change and fail to
materialize, but I intend to at least move away from it.
So there will, someday, be a single control group hierarchy. It will not, however, be tied to the process tree; it will be an independent tree of groups allowing processes to be combined in arbitrary ways. The responses to Tejun's conclusions have mostly focused on details (how to handle controllers that are not fully hierarchical, for example). There does not appear to be any determined opposition to the idea of removing the multiple hierarchy feature at some point when it can be done without breaking systems, so users of control groups should consider the writing to be on the wall. (Log in to post comments)
Prcoess in multiple control groups Posted Mar 15, 2012 12:20 UTC (Thu) by slashdot (guest, #22014) [Link]
What about allowing a process to be a member of multiple cgroups?
This would allow to have a single hierarchy, but still support orthogonal hierarchies as normal children of it.
Each process would be allocated resources according to the sum of the allowances coming from all its cgroup memberships.
Prcoess in multiple control groups Posted Mar 22, 2012 9:41 UTC (Thu) by kevinm (guest, #69913) [Link]
It's not that simple.
Consider if a process was a member of two control groups, one of which has a memory limit of 200MB and one of which has a memory limit of 1G. To which control group should that process's memory be accounted? Half each? In proportion to the memory limits? In proportion to the number of processes in each? Something else?
What happens if one of the two control groups is at its limit, but the other is not - is the process prevented from allocating more memory? If not, how does its memory allocated get accounted now?
It looks like a nightmare.
Prcoess in multiple control groups Posted Mar 22, 2012 10:14 UTC (Thu) by dgm (subscriber, #49227) [Link]
Adding a process to another group should not add to its limits. The limit should always be the most restrictive of all groups. This is simple and predictable, while the alternative becomes complex very quickly.
|
|||||||||||||