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. > 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
Attachment:
signature.asc
Description: Digital signature
