Re: [RFC PATCH] sched/deadline: Avoid dl_server boosting with expired deadline

[Peter Zijlstra]

On Tue, Nov 11, 2025 at 12:17:17PM +0100, Peter Zijlstra wrote:
> On Tue, Nov 11, 2025 at 10:58:51AM +0100, Gabriele Monaco wrote:
> 
> > Is there a reason why dl_server_stop() doesn't reset the running flag?
> 
> Yes. Suppose we're boosting a task, and that task has a small sleep
> (mutex or whatever). The dl_server won't have anything to actually boost
> and will stop itself, clearing running (if dl_server_stop() were to
> clear running).
> 
> Then if the initial fair task wakes up again, we'll (re)start the
> dl_server, but since !running, it will go do the whole defer/zero-laxity
> thing again, making out task wait for a whole period until it can run
> again.
> 
> Conversely (dl_server_stop(), like now, does *not* clear running), if
> running is retained, the dl_server is able to immediately resume its
> still valid runtime.
> 
> Put otherwise, a fair task that always runs and a fair task that has
> micro-sleeps should more or less behave the same. We should not punish a
> micro-sleep with a whole second delay.
> 
> Now, if the sleep is long, we'll find the deadline is in the past and
> then it pushes the activation forward and we go ... Oooh to E.

Ah, no, replenlish_dl_new_period() sets defer_armed = 1, so
start_dl_timer() from enqueue_dl_entity() will end up in zero-laxity
wait.

Damn, so much notes and I still get it wrong :-(