Hi, Michal On Wed, 26 Nov 2025 15:13:13, Michal Koutný wrote: >On Thu, Nov 20, 2025 at 09:05:57PM +0800, Sun Shaojie <[email protected]> >wrote: >> >Do you actually want to achieve this or is it an implementation >> >side-effect of the Case 1 scenario that you want to achieve? >> >> Yes, this is indeed the functionality I intended to achieve, as I find it >> follows the same logic as Case 1. > >So you want to achieve a stable [1] set of CPUs for a cgroup that cannot >be taken away from you by any sibling, correct? >My reasoning is that the siblings should be under one management entity >and therefore such overcommitment should be avoided already in the >configuration. Invalidating all conflicting siblings is then the most >fair result achievable. >B1 is a second-class partition _only_ because it starts later or why is >it OK to not fulfill its requirement? >
If the siblings are under a single management entity, that certainly works. But what if there are multiple administrative users? Should we really violate other users' requirements just to satisfy one user's requirement? Given this, first-come-first-served might be fairer. >[1] Note that A1 should still watch its cpuset.cpus.partition if it >takes exclusivity seriously because its cpus may be taken away by >hot(un)plug or ancestry reconfiguration. Thanks, Sun Shaojie
