linux-kernel - Re: [RFC PATCH v3 00/24] Hierarchical Constant Bandwidth Server

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: <aQiE1ULtInJS6X4R@jlelli-thinkpadt14gen4.remote.csb>
Date: Mon, 3 Nov 2025 11:32:53 +0100
From: Juri Lelli <juri.lelli@...hat.com>
To: luca abeni <luca.abeni@...tannapisa.it>
Cc: Yuri Andriaccio <yurand2000@...il.com>, 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>,
	linux-kernel@...r.kernel.org,
	Yuri Andriaccio <yuri.andriaccio@...tannapisa.it>
Subject: Re: [RFC PATCH v3 00/24] Hierarchical Constant Bandwidth Server

On 24/10/25 10:02, luca abeni wrote:
> Hi Juri,
> 
> On Mon, 20 Oct 2025 11:40:22 +0200
> Juri Lelli <juri.lelli@...hat.com> wrote:
> [...]
> > > > - The first patch which removed fair-servers' bandwidth
> > > > accounting has been removed, as it was deemed wrong. You can find
> > > > the last version of this removed patch, just for history reasons,
> > > > here:
> > > > https://lore.kernel.org/all/20250903114448.664452-1-yurand2000@gmail.com/
> > > >  
> > > 
> > > Peter wasn't indeed happy with that patch, but I am not sure we
> > > finished that discussion. Both myself and Luca had further
> > > objections to what Peter said, but not further replies after (which
> > > can very well be a sign that he is still adamnt in saying no go
> > > away :). Peter?
> > > 
> > > https://lore.kernel.org/lkml/aLk9BNnFYZ3bhVAE@jlelli-thinkpadt14gen4.remote.csb/
> > > https://lore.kernel.org/lkml/20250904091217.78de3dde@luca64/  
> > 
> > I had a quick chat with Peter on IRC about this. We now seem to agree
> > that a third option would be to move to explicitly account
> > dl-server(s), correspondingly moving from a 95% to 100% limit. That
> > would also make our life easier in the future with additional
> > dl-servers (e.g. scx-server).
> > 
> > What do you think?
> 
> This looks like another good solution, thanks!
> 
> So, if I understand well with this approach
> /proc/sys/kernel/sched_rt_{runtime, period}_us would be set to 100% as
> a default, right?
> 
> It is often useful to know what is the maximum CPU utilization that can
> be guaranteed to real-time tasks... With this approach, it would be
> 100% - <dl_server utilization>, but this can change when scx servers are
> added... What about making this information available to userspace
> programs? (maybe /proc/sys/kernel/sched_rt_{runtime, period}_us could
> provide such information? Or is it better to add a new interface?)

Not sure. If we set it to 100% by default (as you suggest, which makes
sense to me) I wonder what would be a usecase/need to set it to less
than 100% later on. We have the debug interface for tweaking dl-servers
and sched_rt_ interface doesn't distinguish between DEADLINE and RT
anyway (so no way to leave some "bandwidth" around for RT tasks).

Maybe it's an interface we want to start deprecating and we can come up
with something better and/or more useful? Peter?