On Fri, Nov 14, 2025 at 09:29:20AM +0800, Chen Ridong chenridong@huaweicloud.com wrote:
After further consideration, I still suggest retaining this rule.
Apologies, I'm slightly lost which rule. I hope the new iteration from Shaojie with both before/after tables will explain it.
For am example: Step | A1's prstate | B1's prstate | #1> mkdir -p A1 | member | | #2> echo "0-1" > A1/cpuset.cpus.exclusive | member | | #3> echo "root" > A1/cpuset.cpus.partition | root | | #4> mkdir -p B1 | root | member | #5> echo "0" > B1/cpuset.cpus | root invalid | member |
Currently, we mark A1 as invalid. But similar to the logic in this patch, why must A1 be invalidated?
A1 is invalidated becase it doesn't have exclusive ownership of CPU 0 anymore.
B1 could also use the parent's effective CPUs, right?
Here you assume some ordering between siblings treating A1 more important than B1. But it's symmetrical in principle, no?
This raises the question: Should we relax the restriction to allow a cpuset's cpus to be a subset of its siblings' exclusive_cpus, thereby keeping A1 valid? If we do this, users may struggle to understand what their cpuset.cpus.effective value is (and why it has that value)—contrary to their expectations.
Not only users, not only users. I think struggle is reduced when the resulting state (valid/invalid, effective) doesn't depend on the order in which individual cgroups are configured.
0.02€, Michal