Hello, Glauber. On Thu, Apr 12, 2012 at 02:04:24PM -0300, Glauber Costa wrote: > 1) Right now, the controllers work independently, and that code will > have to live for at least some years anyway. So leave it there. > > 2) But also, insert optimization code that can be enabled/disabled > when companion cgroups are in the same hierarchy. > > 3) After we mount the cgroup, apply those optimization to all of > them from the cgroup core (the current bind stuff is just way to > weird for that, IMHO) > > 4) Then we start telling userspace people to favor co-mounts as much > as they can > > 5) Pray. Pretty similar to the plan that I was thinking about. * Provide both mechanisms from the kernel while implementing new features / optimizations with the assumption that there's one hierarchy. * Make the switch to single hierarchy from userland, probably by implementing a (policy based) userland thing which takes over the whole cgroup hierarchy. * Phase out multiple hierarchy support from kernel slowly. That said, there are quite a few obstacles including being able to support most (probably not all) use cases possible under multiple hierarchies and managing the added complexity over the transition period. I don't think it's gonna be easy. Needs more thinking. Thanks. -- tejun _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers