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

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

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@vger.kernel.org
>> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
>> ---
> 
> 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@redhat.com>

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