Tejun Heo <tj@xxxxxxxxxx> writes: > On Wed, Jan 07, 2015 at 04:14:40PM -0600, Eric W. Biederman wrote: >> I see what you mean. If it is indeed the case than a mount of cgroupfs >> using the unified hiearchy and can not specify which controllers are >> present under that mount that very significant bug and presents a very >> significant regression in user space flexibility. > > The parent always controls which controllers are made available at the > children level. Only if the parent enables a controller, its > children, whether they're namespaces or not, can choose to further > distribute resources using that controller. It's a straight-forward > top-down thing. Ignoring namespace details for a moment. The following should be possible with a unified hierarchy. If it is not it is a show stopper of a regression. mount -t tmpfs none /sys/fs/cgroup (cd /sys/fs/cgroup ; mkdir cpu cpuacct devices memory) mount -t cgroupfs -o cpu /sys/fs/cgroup/cpu mount -t cgroupfs -o cpuacct /sys/fs/cgroup/cpuacct mount -t cgroupfs -o devices /sys/fs/cgroup/devices mount -t cgroupfs -o memory /sys/fs/cgroup/memory With the expectation that only the control files for the specified controllers show up in those mounts. That is a unified hierarchy is fine. Requiring that there only be one mount point and that every one use it is not ok and it actively a problem. It is absolutely required to be able to avoid b0rked controllers, and to my knowledge the only way to do that is to have multiple mounts where we pick the controller on each mount. Even if there is now a way that doesn't require multiple mounts to keep b0rked controllers from being enabled multiple mounts still need to work to support the existing userspace programs. This discussion is happening because Documentation/cgroups/unified-hierarchy.txt implies the configuration I have just described will not work with unified hierachies enabled. Eric -- 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
