On 8/27/21 5:27 PM, Tejun Heo wrote:
Hello,
On Fri, Aug 27, 2021 at 05:19:31PM -0400, Waiman Long wrote:
Well, that is a valid point. The cpus may have been offlined when a
partition is being created. I can certainly relent on this check in forming
a partition. IOW, cpus_allowed can contain some or all offline cpus and a
valid (some are online) or invalid (all are offline) partition can be
formed. I can also allow an invalid child partition to be formed with an
invalid parent partition. However, the cpu exclusivity rules will still
apply.
Other than that, do you envision any other circumstances where we should
allow an invalid partition to be formed?
Now that most restrictions are removed from configuration side, just go all
the way? Given that the user must check the status afterwards anyway, I
don't see technical or even usability reasons for leaving some pieces
behind. Going all the way would be easier to use too - bang in the target
config and read the resulting state to reliably find out why a partition
isn't valid, especially if we list *all* the reasons so that the user
tell whether the configuration is as intended immediately.
The cpu exclusivity rule is due to the setting of CPU_EXCLUSIVE bit.
This is a pre-existing condition unless you want to change how the
cpuset.cpu_exclusive works.
So the new rules will be:
1) The "cpuset.cpus" is not empty and the list of CPUs are exclusive.
2) The parent cgroup is a partition root (can be an invalid one).
3) The "cpuset.cpus" is a subset of the parent's cpuset.cpus.allowed.
4) No child cgroup with cpuset enabled.
I think they are reasonable. What do you think?
Cheers,
Longman
