Re: [PATCH 1/2] cgroup/cpuset: record DL BW alloc CPU for attach rollback

[Waiman Long <longman@redhat.com>]

On 4/19/26 10:21 PM, Guopeng Zhang wrote:
>
> 在 2026/4/18 2:51, Waiman Long 写道:
>> On 4/16/26 11:37 PM, Guopeng Zhang wrote:
>>> cpuset_can_attach() allocates DL bandwidth only when migrating
>>> deadline tasks to a disjoint CPU mask, but cpuset_cancel_attach()
>>> rolls back based only on nr_migrate_dl_tasks. This makes the DL
>>> bandwidth alloc/free paths asymmetric: rollback can call dl_bw_free()
>>> even when no dl_bw_alloc() was done.
>>>
>>> Rollback also needs to undo the reservation against the same CPU/root
>>> domain that was charged. Record the CPU used by dl_bw_alloc() and use
>>> that state in cpuset_cancel_attach(). If no allocation happened,
>>> dl_bw_cpu stays at -1 and rollback skips dl_bw_free(). If allocation
>>> did happen, bandwidth is returned to the same CPU/root domain.
>>>
>>> Successful attach paths are unchanged. This only fixes failed attach
>>> rollback accounting.
>>>
>>> Fixes: 2ef269ef1ac0 ("cgroup/cpuset: Free DL BW in case can_attach() fails")
>>> Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn>
> ...
>> The patch looks correct to me.
>>
>> Reviewed-by: Waiman Long <longman@redhat.com>
> Hi Waiman,
>
> Thank you for the review and for the Reviewed-by.
>> However, I have a DL bandwidth accounting question unrelated to this patch that I would like the scheduler people to clarify. The allocation of additional DL BW is based on the condition
>>
>>          if (!cpumask_intersects(oldcs->effective_cpus, cs->effective_cpus)) {
>>
>> IOW, additional DL BW will need to be allocated when the old and new cpuset doesn't overlap. However, they could still be in the same root domain. Does that mean we will be double counting it?
> 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.
>> Looking from the other side, the root domain may have enough DL BW for the task migration, but the subset of CPUs in the cpuset itself may not have enough total DL BW to host all the DL tasks to be migrated, is that a problem?
> 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.

Cheers,
Longman

>
> So if a cpuset is only a subset inside a larger root domain, it does not seem
> to get an independent DL bandwidth limit of its own. If that understanding is
> correct, then the smaller cpuset not having enough bandwidth by itself would
> be a limitation of that model rather than something this code checks
> separately. I'd appreciate confirmation from the scheduler folks on that
> point.
>
> Thanks,
> Guopeng
>> Cheers,
>> Longman