On Wed, 20.07.11 16:42, Vivek Goyal (vgoyal@xxxxxxxxxx) 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. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
