Re: [PATCH v6 5/6] cgroup/cpuset: Update description of cpuset.cpus.partition in cgroup-v2.rst

[Tejun Heo]

On Sat, Aug 14, 2021 at 04:57:42PM -0400, Waiman Long wrote:
> +	A parent partition may distribute all its CPUs to its child
> +	partitions as long as it is not the root cgroup and there is no
> +	task directly associated with that parent partition.  Otherwise,

"there is not task directly associated with the parent partition" isn't
necessary, right? That's already enforced by the cgroup hierarchy itself.

> +	there must be at least one cpu left in the parent partition.
> +	A new task cannot be moved to a partition root with no effective
> +	cpu.
> +
> +	Once becoming a partition root, changes to "cpuset.cpus"
> +	is generally allowed as long as the first condition above
> +	(cpu exclusivity rule) is true.

All the above ultimately says is that "a new task cannot be moved to a
partition root with no effective cpu", but I don't understand why this would
be a separate rule. Shouldn't the partition just stop being a partition when
it doesn't have any exclusive cpu? What's the benefit of having multiple its
own failure mode?

> +	Sometimes, changes to "cpuset.cpus" or cpu hotplug may cause
> +	the state of the partition root to become invalid when the
> +	other constraints of partition root are violated.  Therefore,
> +	it is recommended that users should always set "cpuset.cpus"
> +	to the proper value first before enabling partition.  In case
> +	"cpuset.cpus" has to be modified after partition is enabled,
> +	users should check the state of "cpuset.cpus.partition" after
> +	making change to it to make sure that the partition is still
> +	valid.

So, idk why the this doesn't cover the one above it. Also, this really
should be worded a lot stronger. It's not just recommended - confirming and
monitoring the transitions is an integral and essential part of using
cpuset.

...
> +	An invalid partition is not a real partition even though the
> +	restriction of the cpu exclusivity rule will still apply.

Is there a reason we can't bring this in line with other failure behaviors?

> +	In the special case of a parent partition competing with a child
> +	partition for the only CPU left, the parent partition wins and
> +	the child partition becomes invalid.

Given that parent partitions are *always* empty, this rule doesn't seem to
make sense.

So, I think this definitely is a step in the right direction but still seems
to be neither here or there. Before, we pretended that we could police the
input when we couldn't. Now, we're changing the interface so that it
includes configuration failures as an integral part; however, we're still
policing some particular inputs while letting other inputs pass through and
trigger failures and why one is handled one way while the other differently
seems rather arbitrary.

Thanks.

-- 
tejun