On 07/19/2018 12:52 PM, Tejun Heo wrote: > Hello, > > On Thu, Jul 19, 2018 at 11:52:46AM -0400, Waiman Long wrote: >> BTW, the way the partition is currently implemented right now is that a >> child cannot be a partition root unless its parent is a partition root >> itself. That is to avoid turning on partition to affect ancestors >> further up the hierarchy than just the parent. So in the case of a >> container, it cannot allocate sub-partitions underneath it unless it is >> a partition itself. Will that solve your concern? > Hmm... so a given ancestor must be able to both > > 1. control which cpus are moved into a partition in all of its > subtree. Not at the moment. I do have another idea of adding a "cpus.subpart" file, for example, to indicate what CPUs a child sub-partition can use in its partition. This control file only serves as an intention to grant, it won't affect anything else. Before the partition flag can be turned on, the kernel will have to check if the cpu list of the child is also a subset of its parent's cpus.subpart as a precondition. Does that serve the purpose of letting a parent has a say of what CPUs can be included in a child partition? This change will require adding a new cpumask into the cpuset structure, the code to handle the mask as well as an additional check in the partition enable code. That will have minimal impact to the current code. > 2. take away any given cpu from ist subtree. > > Right now, I don't think it's achieving either, right? The only way to take away the CPUs from a sub-partition is to turn off the partition flag in the child provided that it has no sub-partitions underneath it. Do you want a way at the parent level to take CPUs away from child partitions? The "cpus.subpart" file can probably be used also for this purpose, but we have to decide what taking CPUs away from child partition means. Does that mean automatically turn off the partition flag in the children if there is no CPU left in the partition? There are some implementation details that need to be fleshed out. I would prefer not doing this as this will complicate the code without too much benefit that I can see. 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
