Quoting "Daniel Hokka Zakrisson" <daniel@hozac.com>:
>
> What problems does it actually fix? What use-cases does it let us
> support?
>
> Daniel
>
The set of use cases it supports, or a least makes a lot more
manageable are those where it is required that the different cgroups
subsystems are to be applied to divergent subsets of tasks, subsets
where presence in one set does not imply presence in another.For
example, on one particular guest I may wish to have:
* cpuset subsystem allocated a process type basis (for example, 30%
allocated to MySQL, 30% to Apache, 10% to java, etc).
* net_cls allocated on a user basis (for example packets from users
dave,lara,fred will be tagged differently)
I believe that the only way to achieve this mixed allocation would be
to have one directory or sub-directory for each combination, so one
would need either a dave/java/ or a dave_java/ somewhere in
/dev/cgroup/<guestname>. This would mean the total number of
subdirectories needed would be <number of users> x <number of process
types>.
If a third grouping were needed on a separate subsystem in the future,
the situation would be further complicated, necessitating a third
layer of sub-directories.
Also note that I may wish to have another guest on the same host in
which the allocations of tasks are needed in a completely different
hierarchy.
If I'm right and this would be necessary, then if more cgroup
subsystems are added to later kernel which could have use cases where
they are most simply mounted separately, the situation would be
further complicated. It seems to me that mounting the cgroup
subsystems separately makes sense.
Perhaps I lack some cgroup knowledge that would make the sorts of
allocations I envisage possible in an easier way. I'm sure there a
different ways to allocate resources that fit in with the current
method, but I think it would be good to have the flexibility.
I'm also thinking of this on the basis that it may be possible for at
some point for guests to manage their own allocations and create
directories within their own cgroupfs subdirectory. The idea has been
floated on the IRC recently.
Cheers,
==
From Ben Green