On Fri, Nov 14, 2025 at 09:29:20AM +0800, Chen Ridong <[email protected]> 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
signature.asc
Description: PGP signature
