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.
1. cpuset.cpus.exclusive.effective of a valid partition
2. cpuset.cpus.exclusive
3. 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
