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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251031152005.GT3245006@noisy.programming.kicks-ass.net>
Date: Fri, 31 Oct 2025 16:20:05 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Gabriele Monaco <gmonaco@...hat.com>
Cc: Juri Lelli <juri.lelli@...hat.com>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...hat.com>,
	Clark Williams <williams@...hat.com>, arighi@...dia.com
Subject: Re: [RFC PATCH] sched/deadline: Avoid dl_server boosting with
 expired deadline

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 :-)