Re: [PATCH v5 15/29] sched/deadline: Rebuild the root domains' accounting from the task list

[Juri Lelli]

Hello,

On 08/11/26 13:53, Mathieu Desnoyers wrote:
> A rebuild of the root domains, as on CPU hotplug, clears their deadline
> accounting. dl_rebuild_rd_accounting() then adds back the deadline tasks
> of each cpuset. Without CONFIG_CPUSETS, it is a stub. So the first
> hotplug drops every deadline task's bandwidth, and their releases wrap
> total_bw around. In testing, a root domain admitted 9 tasks of 10ms
> every 100ms before a hotplug with deadline sleepers, and none after.
> 
> With cpusets, the rebuild skips a cpuset whose nr_deadline_tasks is 0.
> This count spares suspend and resume a costly walk of all tasks. An
> attach moves it by a tally taken in cpuset_can_attach(). A task that
> leaves the class between the tally and the move is taken off the old
> cpuset twice. Its count can then reach 0 with a deadline task in it.
> Every rebuild would then drop that task's bandwidth.
> 
> Fix both by walking the task list, with or without cpusets. The walk
> finds every deadline task, so the count and its hooks go. It holds
> tasklist_lock for reading, so fork and exit wait meanwhile. It locks
> only deadline tasks, where the walk that the count avoided took the
> pi_lock of every task. It leaves out an exited task with a dl_bw of 0.
> It also leaves out a zombie whose bandwidth an earlier rebuild dropped,
> as dl_clear_root_domains() does.
> 
> Without cpusets, a new dl_accounting_mutex keeps admissions out of a
> rebuild, as cpuset_mutex does with them.
> 
> Three hotplug cases of deadline_bw_test, added later in this series,
> fail without cpusets. With this patch, its five hotplug cases pass, in 4
> VMs. Its death_zombie_hotplug case tests the zombie. The Sashiko AI
> reviews of v3, and of v4 before posting, found the drift and the exited
> tasks. Its review of v4 found the zombie.
> 
> Fixes: f9a25f776d78 ("cpusets: Rebuild root domain deadline accounting information")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx>
> ---

As you most probably know, the count this removes was added because Qais
reported 10-20ms suspend/resume regressions from the old walk on
Android, and the merged fix was validated only as "delay no longer
noticeable" on zero-DL systems. Added him in Cc.

The new walk drops the per-task pi_lock that dominated the old cost, so
the approach might be OK, but since this is Cc: stable and will
eventually reach Android, maybe someone from there can confirm before we
pull the trigger?

Alternatively, a single global "any deadline task exist" bail would keep
suspend/resume free for the no-DL case without reintroducing any
per-cpuset bookkeeping to drift?

Thanks,
Juri