Control groups, part 5: The cgroup hierarchy

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).