Re: [PATCH v5 07/29] sched/deadline: Do not lose a throttled task switched out and back

[Mathieu Desnoyers]

On 2026-11-09 11:05, Juri Lelli wrote:
> Hello,
>
> On 08/11/26 13:53, Mathieu Desnoyers wrote:
> > A SCHED_DEADLINE task can be throttled, switched to another policy, and
> > switched back before its 0-lag time. It may then never run again, not
> > even to die of a fatal signal.
> >
> > A task that leaves SCHED_DEADLINE keeps its parameters until its 0-lag
> > time, so that leaving and coming back gains nothing. Commit 209a0cbda7a0
> > ("sched/deadline: Improve the tracking of active utilization") moved
> > their reset from the replenishment timer to the inactive timer, which
> > switched_to_dl() cancels.
> >
> > This misses a task that was throttled when it left. An overrun can put
> > its 0-lag time after its replenishment timer. That timer fires while
> > the task is out of the class, and does nothing. On the return of the
> > task, enqueue_dl_entity() leaves it to that timer, which has fired. The
> > task is then on no dl_rq, with no timer pending, until it leaves
> > SCHED_DEADLINE again.
> >
> > Fix this by replenishing the task when the timer finds it out of the
> > class, as for a throttled task that is not queued. Its return then
> > enqueues it.
> >
> > Clearing dl_throttled alone would not do. It would forgive the overrun.
> > A yield left set, or the old deadline of a constrained task, would
> > throttle the task again. The Sashiko AI review of the first posting
> > found this in the first version of this patch.
> >
> > A cgroup selftest under development hung on this bug about once in
> > 1350 runs. The throttled_round_trip case of deadline_switch_test, added
> > later in this series, fails 8 times out of 8 on v7.3 and v7.4-rc1. It
> > passes with this patch.
> >
> > Fixes: 209a0cbda7a0 ("sched/deadline: Improve the tracking of active utilization")
> > Cc: stable@xxxxxxxxxxxxxxx
> > Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx>
> > ---
>
> this still fixes the hang, so my v2 comment stands: take it, and keep
> working the potential additional re-entry corners separately.
>
> Acked-by: Juri Lelli <juri.lelli@xxxxxxxxxx>

Noted, thanks!

> 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.

Thanks,

Mathieu


--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com