Hello, Waiman. On Fri, May 19, 2017 at 05:20:01PM -0400, Waiman Long wrote: > > This breaks the invariant that in a cgroup its resource control knobs > > control distribution of resources from its parent. IOW, the resource > > control knobs of a cgroup always belong to the parent. This is also > > reflected in how delegation is done. The delegatee assumes ownership > > of the cgroup itself and the ability to manage sub-cgroups but doesn't > > get the ownership of the resource control knobs as otherwise the > > parent would lose control over how it distributes its resources. > > One twist that I am thinking is to have a controller enabled by the > parent in subtree_control, but then allow the child to either disable it > or set it in pass-through mode by writing to controllers file. IOW, a > child cannot enable a controller without parent's permission. Once a > child has permission, it can do whatever it wants. A parent cannot force > a child to have a controller enabled. Heh, I think I need more details to follow your proposal. Anyways, what we need to guarantee is that a descendant is never allowed to pull in more resources than its ancestors want it to. > > Another aspect is that most controllers aren't that sensitive to > > nesting several levels. Expensive operations can be and already are > > aggregated and the performance overhead of several levels of nesting > > barely shows up. Skipping levels can be an interesting optimization > > approach and we can definitely support from the core side; however, > > it'd be a lot nicer if we could do that optimization transparently > > (e.g. CPU can skip multi level queueing if there usually is only one > > item at some levels). > > The trend that I am seeing is that the total number of controllers is > going to grow over time. New controllers may be sensitive to the level > of nesting like the cpu controller. I am also thinking about how systemd > is using the cgroup filesystem for task classification purpose without > any controller attached to it. With this scheme, we can accommodate all > the different needs without using different cgroup filesystems. I'm not sure about that. It's true that cgroup hierarchy is being used more but there are only so many hard / complex resources that we deal with - cpu, memory and io. Beyond those, other uses are usually about identifying membership (perf, net) or propagating and restricting attributes (cpuset). pids can be considered an exception but we have it only because pids can globally run out a lot sooner than can be controlled through memory. Even then, it's trivial. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
