Am 07.01.2015 um 00:20 schrieb Aditya Kali: > I understand your point. But it will add some complexity to the code. > > Before trying to make it work for non-unified hierarchy cases, I would > like to get a clearer idea. > What do you expect to be mounted when you run: > container:/ # mount -t cgroup none /sys/fs/cgroup/ > from inside the container? I expect cgroupfs to behave exactly as it would in the initial namespace. Such that the container can do with it whatever it wants. systemd mounts and manages cgroups on its own. Like for CONFIG_DEVPTS_MULTIPLE_INSTANCES. If a new cgroup namespace cannot provide a clean and autonomous cgroupfs instance it is fundamentally flawed. You cannot provide a namespace mechanism which depends on the host side that much. This will also horrible break container migrations between hosts. i.e. Migrate a container from a Ubuntu host to a Fedora (systemd!) host. > Note that cgroup-namespace wont be able to change the way cgroups are > mounted .. i.e., if say cpu and cpuacct subsystems are mounted > together at a single mount-point, then we cannot mount them any other > way (inside a container or outside). This restriction exists today and > cgroup-namespaces won't change that. Why can't cgroup namespace change this? I think of cgroup namespace as a new and clean cgroupfs instance which inherits all limits from the outside. > So, If on the host we have: > root@adityakali-vm2:/sys/fs/cgroup# cat /proc/mounts | grep cgroup > tmpfs /sys/fs/cgroup tmpfs rw,relatime 0 0 > cgroup /sys/fs/cgroup/cpu cgroup rw,relatime,cpuset,cpu,cpuacct 0 0 > cgroup /sys/fs/cgroup/mem cgroup rw,relatime,memory,hugetlb 0 0 > cgroup /sys/fs/cgroup/rest cgroup > rw,relatime,devices,freezer,net_cls,blkio,perf_event,net_prio 0 0 > > And inside the container we want each subsystem to be on its own > mount-point, then it will fail. Do you think even then its useful to > support virtualizing paths for non-unified hierarchies? As I've stated above I expect from cgroup namespaces a clean and sane cgroupfs instance no matter how the outer mounts are. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
