Control groups, part 5: The cgroup hierarchy

Posted Aug 8, 2014 1:52 UTC (Fri) by IkeTo (subscriber, #2122)
Parent article: Control groups, part 5: The cgroup hierarchy

I find the following difficult to follow:

If we included the net_cl subsystem in the systemd hierarchy described earlier, we would potentially need to create several sub-cgroups in each session for the different network classes that might be required. If other subsystems (e.g. cpu or blkio) wanted different classifications within each session, a combinatorial explosion of cgroups could result.

It isn't immediately clear to me how "create several sub-cgroups in each session" would work at all.

The Documentation/cgroups/cgroups.txt file is of a little help, but not sufficient for me to fully understand the alternative. It describes a scenario that the admin can raise the capability of a task temporarily in only one of the subsystems but not others. I can imagine that, instead of using a student's own quota in CPU when working for a professor, he can be configured to use the quota of the professor just for the CPU when running the simulator program.

What I don't see is, how that can be achieved without multiple hierarchies, even if creation of many sub-cgroups is allowed? Sure we can create a sub-cgroup of "student" as "student with professor cpu quota", but that cgroup cannot simultaneously be the child of the student cgroup and the professor cgroup with a single hierarchy. Perhaps it will all become very clear once part 7 is read.

Control groups, part 5: The cgroup hierarchy

Posted Aug 9, 2014 5:33 UTC (Sat) by neilbrown (subscriber, #359) [Link]

Thanks for asking - I did wonder if I had explained that well enough.

If we wanted to set the network class for sockets created by one set of processes that "joe" creates to "3" and for sockets created by some other set to "4", then in each session owned by "joe" we need two cgroups. Maybe call them "netcl_3" and "netcl_4".
If we have some other users logged in they will also each need "netcl_3" and "netcl_4" in their "session scope" cgroup.

These are the "several sub-cgroups in each session". We can assign lots of different cgroups the network class number of '3' and lots of others the network class number of '4'.

Suppose that we also want to restrict different process to different CPU sets, but this division of processes is quite independent of the divisiion by network class. Suppose there are two interesting sets of CPUs called "A" and "B".

Then each different session needs 4 cgroups: "netcl_3_cpu_A", "netcl_3_cpu_B" "netcl_4_cpu_A" "net_cl_cpu_B" (though other arrangements are possible).

If you wanted a different breakdown for imposing device access restrictions (for example) you would need many more groups, in each session. This is the "combinatorial explosion".

This only really works for the non-accounting cgroups. For CPU and memory you cannot achieve a useful effect by multiplying cgroups like this (at least I, like you, cannot see how).