On 7/10/23 21:00, Tejun Heo wrote:
Hello,
On Mon, Jul 10, 2023 at 08:33:11PM -0400, Waiman Long wrote:
I would like to clarify that withdrawal of CPUs from cpuset.cpus.exclusive
is always allowed. It is the addition of CPUs not presents in cpuset.cpus
that will be rejected. The invariant is that cpuset.cpus.exclusive must
always be a subset of cpuset.cpus. Any change that violates this rule is not
allowed. Alternately I can silently dropped the offending CPUs without
returning an error, but that may surprise users.
Right, that'd be confusing.
BTW, withdrawal of CPUs from cpuset.cpus will also withdraw them from
cpuset.cpus.exclusive, if present. This allows the partition code to use
cpuset.cpus.exclusive directly to determine the allowable exclusive CPUs
without doing an intersection with cpuset.cpus each time it is used.
This is kinda confusing too, I think. Changing cpuset.cpus in an ancestor
doesn't affect the contents of the descendants' cpuset.cpus files but would
directly modify the contents of their cpuset.cpus.exclusive files.
There's some inherent friction because cpuset.cpus separates configuration
(cpuset.cpus) and the current state (cpuset.cpus.effective) while
cpuset.cpus.exclusive is trying to do both in the same interface file. When
the two behavior modes collide, it becomes rather confusing. Do you think
it'd make sense to make cpus.exclusive follow the same pattern as
cpuset.cpus?
I don't want to add another cpuset.cpus.exclusive.effective control
file. One possibility is to keep another effective masks in the struct
cpuset and list both exclusive cpus set by the user and the effective
ones side by side, like "<cpus> (<effective_cpus>)" if they differ or
some other format. What do you think?
Regards,
Longman
