On Fri, Sep 14, 2012 at 01:39:25PM -0700, Tejun Heo wrote: > Hello, again. > > On Fri, Sep 14, 2012 at 12:49:50PM -0700, Tejun Heo wrote: > > That said, if someone can think of a better solution, I'm all ears. > > One thing that *has* to be maintained is that it should be able to tag > > a resource in such way that its associated controllers are > > identifiable regardless of which task is looking at it. > > So, I thought about it more. How about we do "consider / ignore this > node" instead of "(don't) nest beyond this level". For example, let's > assume a tree like the following. > > R > / | \ > A B C > / \ > AA AB > > If we want to differentiate between AA and AB, we'll have to consider > the whole tree with the previous sheme - A needs to nest, so R needs > to nest and we end up with the whole tree. Instead, if we have honor > / ignore this node. We can set the honor bit on A, AA and AB and see > the tree as > > R > / > A > / \ > AA AB > > We still see the intermediate A node but can ignore the other > branches. Implementation and concept-wise, it's fairly simple too. > For any given node and controller, you travel upwards until you meet a > node which has the controller enabled and that's the cgroup the > controller considers. I think this proposal sounds reasonable. So by default if a new cgroup is created, we can inherit the controller settings of parent. And if user does not want to enable particular controller on newly created cgroup, it shall have to explicitly disable it. Thanks Vivek _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
