Hi! On 2026-04-19 22:31:29-04:00, Waiman Long wrote: > On 4/19/26 10:21 PM, Guopeng Zhang wrote: > > > 在 2026/4/18 2:51, Waiman Long 写道: > > ... > > Hi Waiman, > > > > Thank you for the review and for the Reviewed-by. > > I think you are right to call this out. Looking at the > > current logic, !cpumask_intersects(oldcs->effective_cpus, > > cs->effective_cpus) > > does not obviously guarantee that the migration is crossing into a different > > root domain. If the old and new cpusets are disjoint but still belong to the > > same root domain, it does look possible that we reserve bandwidth on the > > destination side without a corresponding subtraction from the source side. > > I will try to reproduce that configuration and follow up with results. > > my current understanding is that the DL bandwidth > > accounting is done at root-domain granularity, not at arbitrary > > cpuset-subset > > granularity. > > That is my understanding too. > > > That also seems consistent with > > Documentation/scheduler/sched-deadline.rst, which says that deadline tasks > > cannot have a CPU affinity mask smaller than the root domain they are > > created > > on, and that a restricted CPU set should be achieved by creating a > > restricted > > root domain with cpuset. > > A root domain should be created by creating cpuset root partition for v2 > or using the cpuset.cpu_exclusive flag in v1. > > What is listed in the documentation is the ideal case, but users may not > strictly follow the rule.
But, if they don't and try to create DEADLINE task on cpusets that are subsets of a root-domain, that should fail, as the affinity mask won't be covering the entire root domain. So no BW allocated (and no additional data structures) for subsets either. Thanks, Juri
