Re: [PATCH v4 8/9] cgroup/cpuset: Documentation update for partition

From: Waiman Long
Date: Mon Jul 10 2023 - 23:25:33 EST


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