On 07/20/2018 11:56 AM, Tejun Heo wrote: > Hello, Peter. > > On Fri, Jul 20, 2018 at 05:44:54PM +0200, Peter Zijlstra wrote: >>> The currently proposed implementation is somewhere in the middle. It >>> kinda gets there by restricting a partition to be a child of another >>> partition, which may be okay but it does make the whole delegation >>> mechanism less useful. >> So the implementation does not set ownership of the 'partition' file to >> that of the parent directory? Because _that_ is what I understood from >> Waiman (many versions ago). And that _does_ allow delegation to work >> nicely. > So, that part isn't the problem. The problem is that if we allow > partitioning nested further away from ancestor, the descendant would > be able to take away reources from the removed ancestor. Waiman > avoids this problem by only allowing partitions to nest but then it's > kinda weird cuz it's just a separate tree. The rationale behind the current design is that a parent is allowed to create a child partition if it fully owns all the cpus it has. That is true only if it is a partition itself. IOW, making a cpuset a partition won't affect any ancestors other than the parent. >>>>> 2. take away any given cpu from ist subtree. >>>> I really hate this obsession of yours and doubly so for partitions. But >>>> why would this currently not be allowed? >>> Well, sorry that you hate it. It's a fundamental architectural >>> constraint. If it can't satisfy that, it should't be in cgroup. >> So is hierarchical behaviour; but you seem willing to forgo that. > Well, we do have root or first-level only things. Things just need to > be properly delegatable when they're hierarchical (and things should > be hierarchical only when that actually means something). While not > desirable, considering the history, accomodating this specific usage > that way seems acceptable to me. I am not against the idea of making it hierarchical eventually. I am just hoping to get thing going by merging the patchset in its current form and then we can make it hierarchical in a followup patch. Cheers, Longman -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
