On 6/26/21 6:53 AM, Tejun Heo wrote:
Hello, Waiman. On Mon, Jun 21, 2021 at 02:49:20PM -0400, Waiman Long wrote:1) A partition root can't be changed to member if it has child partition roots. 2) Removing CPUs from cpuset.cpus that causes it to become invalid is not allowed.I'm not a fan of this approach. No matter what we have to be able to handle CPU removals which are user-iniated operations anyway, so I don't see why we're adding a different way of handling a different set of operations. Just handle them the same?
The main reason for doing this is because normal cpuset control file actions are under the direct control of the cpuset code. So it is up to us to decide whether to grant it or deny it. Hotplug, on the other hand, is not under the control of cpuset code. It can't deny a hotplug operation. This is the main reason why the partition root error state was added in the first place.
Normally, users can set cpuset.cpus to whatever value they want even though they are not actually granted. However, turning on partition root is under more strict control. You can't turn on partition root if the CPUs requested cannot actually be granted. The problem with setting the state to just partition error is that users may not be aware that the partition creation operation fails. We can't assume all users will do the proper error checking. I would rather let them know the operation fails rather than relying on them doing the proper check afterward.
Yes, I agree that it is a different philosophy than the original cpuset code, but I thought one reason of doing cgroup v2 is to simplify the interface and make it a bit more erorr-proof. Since partition root creation is a relatively rare operation, we can afford to make it more strict than the other operations.
Cheers, Longman
