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

[Peter Zijlstra <peterz@infradead.org>]

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.

Let me go draw that line in the diagram.