On 12/3/21 13:25, Michal Koutný wrote:
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'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.
That makes sense. I will keep those child partitions in an invalid state
then.
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.)
Yes, that will be automatic and the partition will become valid again if
other events cause changes that unbreak the validity constraints.
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.)
Cheers,
Longman
