Hello Longman.
On Wed, Dec 01, 2021 at 08:28:09PM -0500, Waiman Long <longman@xxxxxxxxxx> wrote:
1) The limitation that "cpuset.cpus" has to be a superset of child'sSuperb!
"cpuset.cpus" has been removed as a new patch to remove that limitation will
be added.
2) The initial transition from "member" to partition root now requires thatThat's sensible.
"cpuset.cpus" overlap with that of the parent's "cpuset.cpus" instead of
being a superset.
For the transition back to "member", I haven't changed the current wordingI wrote I was indifferent about this in a previous mail but when I think
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.
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.
Yes, that will be automatic and the partition will become valid again if other events cause changes that unbreak the validity constraints.
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!
[...]s/can be/will be/
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.
(I understand the intention is to make it asynchronously and
automatically, i.e. without writing into the affected descendant(s)
cpuset.partition again.)
Cheers,
Poll and inotify events are triggered whenever the state of-> that change validity status
"cpuset.cpus.partition" changes. That includes changes caused by
write to "cpuset.cpus.partition", cpu hotplug and other changes
that make the partition invalid.
(In accordance with the comment above.)