Re: [PATCH v5 07/29] sched/deadline: Do not lose a throttled task switched out and back
From: Mathieu Desnoyers
Date: Mon Nov 09 2026 - 14:02:55 EST
On 2026-11-09 11:29, Mathieu Desnoyers wrote:
On 2026-11-09 11:05, Juri Lelli wrote:[...]
Hi Juri,
Still have to review them properly, but between 09/29 and 24/29 I
believe every return at or after the 0-lag time is now covered, that was
the bulk of what I was "seeing more of" in my v2 review.
What I think is still open is the other half: a return before the 0-lag
time, with different parameters, where the budget carried over from the
old reservation is never validated against the new one. IIUC that can
only buy a task one instance past its new admission (it converges at the
next replenishment), so it should not block this series and we can
discuss separately/later on. Just mentioning here so that I hopefully
don't forget.
Your insight points to a coverage hole in my proposed test cases (last
patches of the series). Let's see if I can improve coverage there.
A heads-up on the case you pointed out: a return before the 0-lag
time, with different parameters.
It is real, and older than this series. On v7.4-rc1, a task of 50ms
every 100ms came back through SCHED_OTHER with 10ms. It then ran 39ms
of the next 100ms. If the task is asleep when it comes back, its wakeup
checks the runtime left with dl_entity_overflow(). If it is runnable,
nothing checks it.
The same happens without leaving the class. A runnable task that
shrinks its parameters keeps the runtime left from the old ones. Since
40767b0dc768, new parameters take effect at the next period. But the
old bandwidth is released at once, as the XXX comment in
sched_dl_overflow() says.
For v6, I plan two fixes, after the current patch 27:
- 28: a task that enters the class runnable gets the wakeup rule,
update_dl_entity(). Fixes: a649f237db18.
- 29: the same after sched_setattr() changes the runtime, deadline or
period of a runnable task. __setparam_dl() sets a dl_new_params bit
for the next enqueue. The enqueue flags cannot tell this case: a
cgroup move also uses ENQUEUE_MOVE. Fixes: 40767b0dc768.
A task whose runtime left fits the new parameters keeps it. So it
never gets more than a wakeup would give it.
I also plan three deadline_bw_test cases. return_running_new_params
and change_running_new_params fail on v7.4-rc1, and pass with the
planned fixes. return_asleep_new_params passes everywhere: it covers
the wakeup path.
Patch 29 changes the choice of 40767b0dc768 for a task that shrinks.
You may prefer to keep it, and delay the bandwidth release as the XXX
comment suggests. Then I would leave 29 out of v6.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com