new cg-manager gui tool for managin cgroups

[Vivek Goyal]

On Wed, Jul 20, 2011 at 11:07:14PM +0200, Lennart Poettering wrote:
> On Wed, 20.07.11 16:42, Vivek Goyal (vgoyal at redhat.com) wrote:
> 
> > 
> > On Wed, Jul 20, 2011 at 10:28:32PM +0200, Lennart Poettering wrote:
> > 
> > [..]
> > > 
> > > > Right now, the gui assumes that the various hierarchies are mounted separately,
> > > > but that the cpu and cpuacct are co-mounted. Its my understanding that this
> > > > is consistent with how systemd is doing things. So that's great.
> > > 
> > > In F15 we mount all controllers enabled in the kernel separately. In F16
> > > we'll optionally mount some of them together, and we'll probably ship a
> > > default of mounting cpu and cpuacct together if they are both enabled.
> > 
> > Last time we talked about possibility of co-mounting memory and IO at some
> > point of time and you said it is a bad idea from applications programming
> > point of view.  Has that changed now?
> 
> Well, no, but yes.
> 
> After discussing this Dhaval the scheme we came up with is to add
> symlinks to /sys/fs/cgroup/ so that even when some controllers are
> mounted together they are still available at the the separate
> directories. Example, if we mount cpu+cpuacct together things will look
> like this:
> 
> /sys/fs/cgroup/cpu+cpuacct is the joint mount point.
> 
> /sys/fs/cgroup/cpu → /sys/fs/cgroup/cpu+cpuacct is a symlink.
> 
> /sys/fs/cgroup/cpuacct → /sys/fs/cgroup/cpu+cpuacct is a symlink.
> 
> That way to most applications it will be very easy to support this: they
> can simply assume that the controller "foobar" is available under
> /sys/fs/cgroup/foobar, and that's it.

I guess this will be reasonable. Just that application need to handle
the case that directory they are about to create might already be present
there.

So down the we should be able to co-mount memory and IO together with
additional symlinks?

Thanks
Vivek