On 7/10/23 21:07, Tejun Heo wrote:
Hello,
On Mon, Jul 10, 2023 at 08:53:18PM -0400, Waiman Long wrote:
For local partition, it doesn't make sense to have a cpust.cpus.exclusive
that is not the same as cpuset.cpus as it artificially reduce the set of
CPUs that can be used in a partition. In the case of a remote partition, the
Yeah, I was wondering about local partitions. "Automatic but can be
overridden" behavior becomes confusing if it's difficult for the user to
easily tell which part is automatic when. I wonder whether it'd be better to
make the condition static - e.g. for a partition cgroup, cpus.exclusive
always contains all bits in cpus no matter what value is written to it. Or,
if we separate out cpus.exclusive and cpus.exclusive.effective, no matter
what cpus.exclusive is set, a partition root's cpus.exclusive.effective
always includes all bits in cpus.effective.
With no offline CPUs, cpus.effective should be the same as
cpus.exclusive.effective for a valid partition root. Here
cpus.exclusive.effective is a bit different from cpus.effective as it
can contain offline cpus. It also mean that adding
cpus.exclusive.effective can be redundant.
As said before, I try to avoid adding new cpuset control file unless
absolutely necessary. I now have a slight different proposal. Once
manually set, I can keep cpuset.cpus.exclusive invariant. I do need to
do a bit more work when enabling a partition root to find out the
effective set of exclusive CPUs to be used or make the partition invalid
if no exclusive CPU is available. I still want to do a initial check
when setting cpuset.cpus.exclusive to make sure that the value is at
least valid at the beginning.
Do you think this is an acceptable compromise?
Thanks,
Longman
