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

[Peter Zijlstra]

On Fri, Oct 31, 2025 at 02:24:17PM +0100, Gabriele Monaco wrote:
> On Fri, 2025-10-31 at 14:05 +0100, Peter Zijlstra wrote:
> > On Thu, Oct 30, 2025 at 07:42:05PM +0100, Peter Zijlstra wrote:
> > > On Wed, Oct 22, 2025 at 12:11:51PM +0200, Gabriele Monaco wrote:
> > > > 
> > > > Is this expected?
> > > 
> > > Sort of, that was next on the list. Let me see if I can make it stop a
> > > little more.
> > 
> > OK, so I've gone over things again and all I got was a comment.
> > 
> > That is, today I think it all works as expected.
> > 
> > The dl_server will stop once the fair class goes idle long enough. Can
> > you confirm this?
> > 
> 
> I'm going to go through your comment more carefully, but what I can observe now
> is a bit different:
> 
> After this patch, consuming bandwidth in background on fair tasks and on idle is
> equivalent. Updating idle time does effectively replenish after exhausting
> runtime and we never stop the server (IMO this is correct behaviour only for
> fair tasks, since there's potentially something to do).
> At least this is the behaviour I get on a mostly idle system.
> 
> Different scenario if I have the CPU busy with other tasks (e.g. RT policies),
> there I can see the server stopping and starting again.
> After I do this I seem to get a different behaviour (even some boosting after
> idle), I'm trying to understand what's going on.
> 
> Does this behaviour make sense to you?

Ooooh, because idle time is accounted against the server budget too.

That is, idle and running fair are both [2] in my comment. So we never
get to [5].

Humm, let me noodle a bit more on this. Also, I should see if I can get
graphviz to draw ascii art state diagrams :-)