Hello Longman.

On Wed, Dec 01, 2021 at 08:28:09PM -0500, Waiman Long [off-list ref] wrote:

1) The limitation that "cpuset.cpus" has to be a superset of child's
"cpuset.cpus" has been removed as a new patch to remove that limitation will
be added.

Superb!

2) The initial transition from "member" to partition root now requires that
"cpuset.cpus" overlap with that of the parent's "cpuset.cpus" instead of
being a superset.

That's sensible.

For the transition back to "member", I haven't changed the current wording
of forcing child partition roots to become "member" yet. If you think
keeping them as invalid partition root is better, I can made that change
too.

I wrote I was indifferent about this in a previous mail but when I think
about it now, switching to invalid root is perhaps better than switching
to member since it'd effectively mean that modifications of the parent
config propagate (permanently) also to a descendant config, which is
an undesired v1-ism.

Please let me know what other changes you would like to see.

I hope my remarks below are just clarifications and not substantial
changes. Besides that I find your new draft good. Thanks!

[...]

    An invalid partition root can be reverted back to a valid one
    if none of the validity constraints of a valid partition root
    are violated.

s/can be/will be/ 

(I understand the intention is to make it asynchronously and
automatically, i.e. without writing into the affected descendant(s)
cpuset.partition again.)

    Poll and inotify events are triggered whenever the state of
    "cpuset.cpus.partition" changes.  That includes changes caused by
    write to "cpuset.cpus.partition", cpu hotplug and other changes
    that make the partition invalid.

-> that change validity status

(In accordance with the comment above.)


Michal