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: <20251024100227.6ab1bfde@luca64>
Date: Fri, 24 Oct 2025 10:02:27 +0200
From: luca abeni <luca.abeni@...tannapisa.it>
To: Juri Lelli <juri.lelli@...hat.com>
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

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


			Thanks,
				Luca