Subject: Re: [vserver] Treament of Cgroup filesystems by util-vserver
From: ben@bristolwireless.net
Date: Sun, 14 Mar 2010 11:07:50 +0000
Sun, 14 Mar 2010 11:07:50 +0000
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

["application/pgp-signature" not shown]