linux-kernel - Re: [PATCH 04/11] sched/deadline: Add support to initialize and remove dl

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] [day] [month] [year] [list]

Message-ID: <aQ35vUAOD6CflvCA@jlelli-thinkpadt14gen4.remote.csb>
Date: Fri, 7 Nov 2025 14:53:01 +0100
From: Juri Lelli <juri.lelli@...hat.com>
To: Andrea Righi <arighi@...dia.com>
Cc: Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Dietmar Eggemann <dietmar.eggemann@....com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
	Valentin Schneider <vschneid@...hat.com>, Tejun Heo <tj@...nel.org>,
	David Vernet <void@...ifault.com>,
	Changwoo Min <changwoo@...lia.com>, Shuah Khan <shuah@...nel.org>,
	Joel Fernandes <joelagnelf@...dia.com>,
	Christian Loehle <christian.loehle@....com>,
	Emil Tsalapatis <emil@...alapatis.com>,
	Luigi De Matteis <ldematteis123@...il.com>,
	sched-ext@...ts.linux.dev, bpf@...r.kernel.org,
	linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 04/11] sched/deadline: Add support to initialize and
 remove dl_server bandwidth

On 06/11/25 18:09, Andrea Righi wrote:
> On Thu, Nov 06, 2025 at 10:49:20AM +0100, Juri Lelli wrote:
> > Hi,
> > 
> > On 29/10/25 20:08, Andrea Righi wrote:
> > > During switching from sched_ext to fair tasks and vice-versa, we need
> > > support for intializing and removing the bandwidth contribution of
> > > either DL server.
> > 
> > My first and more general/design question is do we strictly need this
> > automagic bandwidth management. We seem to agree [1] that we want to
> > move towards explicit dl-server(s) and tasks bandwidth handling, so we
> > might want to consider leaving the burden completely to whomever might
> > be configuring the system.
> 
> I think we decided to take this approach because, once a sched_ext
> scheduler is loaded and all tasks are moved to the ext class, the fair
> class becomes "empty", but the fair dl-server would still keep its
> bandwidth reserved, so somehow we need to release that reservation,
> right?

Right. I was just alluding to the fact that keeping the "empty"
fair_server reservations is not wrong, but indeed sub-optimal. I didn't
want to block this series if we don't get the automagical removal right,
so wondered if it could be left for later (as we will still have a
manual way to remove the empty reservations anyway :).

...

> > > +
> > > +		hrtimer_cancel(&dl_se->inactive_timer);
> > 
> > I am not sure we actually need to force cancel the timer (but still
> > contradicting myself every time I go back at staring at code :). The way
> > I believe this should work 'in theory' is
> > 
> >  - we remove a server (either automagic or user sets runtime to 0 -
> >    which is probably to fix/look at in current implementation as well
> >    btw)
> >  - current bandwidth is retained and only freed (and server reset) at
> >    0-lag (when inactive_timer fires)
> >  - if server is activated back before 0-lag it will use it's current
> >    parameters
> >  - after 0-lag it's a new instance with new parameters
> 
> Hm... that means just setting the runtime to 0 IIUC. I think I tried that
> approach in the past, but I was seeing some inconsistencies with the
> total_bw kselftest, starting/stopping an scx scheduler multiple times
> seemed to gradually consume all the available bandwidth.
> 
> But I can give it another try, maybe that behavior was caused by other
> issues, since we've fixed quite a few things since then.

Or maybe it could be inactive_timer/dl_non_contending handling that
still has some problems.

Anyway, I noticed that it is still possible to write runtime values of
fair_server while/after scx_server took over. Those values get
overridden when scx_server switches off. Guess we want to prevent writes
while scx_server has full control?