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 sunshaojie@kylinos.cn 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