On 1/4/26 2:53 AM, Chen Ridong wrote:
On 2026/1/2 3:15, Waiman Long wrote:
Currently, when setting a cpuset's cpuset.cpus to a value that conflicts with the cpuset.cpus/cpuset.cpus.exclusive of a sibling partition, the sibling's partition state becomes invalid. This is overly harsh and is probably not necessary.
The cpuset.cpus.exclusive control file, if set, will override the cpuset.cpus of the same cpuset when creating a cpuset partition. So cpuset.cpus has less priority than cpuset.cpus.exclusive in setting up a partition. However, it cannot override a conflicting cpuset.cpus file in a sibling cpuset and the partition creation process will fail. This is inconsistent. That will also make using cpuset.cpus.exclusive less valuable as a tool to set up cpuset partitions as the users have to check if such a cpuset.cpus conflict exists or not.
Fix these problems by strictly adhering to the setting of the following control files in descending order of priority when setting up a partition.
- cpuset.cpus.exclusive.effective of a valid partition
- cpuset.cpus.exclusive
- cpuset.cpus
Hi, Longman,
This description is a bit confusing to me. cpuset.cpus.exclusive and cpuset.cpus are user-settable control files, while cpuset.cpus.exclusive.effective is a read-only file that reflects the result of applying cpuset.cpus.exclusive and cpuset.cpus after conflict resolution.
A partition can be established as long as cpuset.cpus.exclusive.effective is not empty. I believe cpuset.cpus.exclusive.effective represents the final effective CPU mask used for the partition, so it shouldn't be compared in priority with cpuset.cpus.exclusive or cpuset.cpus. Rather, the latter two are inputs that determine the former.
Yes, that priority list can be somewhat confusing. I will take out this paragraph. The next 2 paragraphs in the commit log should be good enough.
Thanks, Longman