[PATCHv3 8/8] cgroup: Add documentation for cgroup namespaces

Richard Weinberger richard at nod.at
Tue Jan 6 23:39:02 UTC 2015


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 at 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


More information about the Containers mailing list