linux-kernel - Re: [PATCH 05/16] sched/deadline: Return EBUSY if dl_bw

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: <20250904091217.78de3dde@luca64>
Date: Thu, 4 Sep 2025 09:12:17 +0200
From: luca abeni <luca.abeni@...tannapisa.it>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Juri Lelli <juri.lelli@...hat.com>, Andrea Righi <arighi@...dia.com>,
 Ingo Molnar <mingo@...hat.com>, 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>, Joel
 Fernandes <joelagnelf@...dia.com>, Tejun Heo <tj@...nel.org>, David Vernet
 <void@...ifault.com>, Changwoo Min <changwoo@...lia.com>, Shuah Khan
 <shuah@...nel.org>, sched-ext@...ts.linux.dev, bpf@...r.kernel.org,
 linux-kernel@...r.kernel.org, Yuri Andriaccio <yurand2000@...il.com>
Subject: Re: [PATCH 05/16] sched/deadline: Return EBUSY if dl_bw_cpus is
 zero

Hi Peter,

On Wed, 3 Sep 2025 22:05:20 +0200
Peter Zijlstra <peterz@...radead.org> wrote:
[...]
> > Yuri is proposing to ignore dl-servers bandwidth contribution from
> > admission control (as they essentially operate on the remaining
> > bandwidth portion not available to RT/DEADLINE tasks):
> > 
> > https://lore.kernel.org/lkml/20250903114448.664452-1-yurand2000@gmail.com/
> > 
> > His patch should make this patch not required. Would you be able and
> > willing to test this assumption?
> > 
> > I don't believe Peter already expressed his opinion on what Yuri is
> > proposing, so this might be moot.   
> 
> Urgh, yeah, I don't like that at all. That reasoning makes no sense
> what so ever. That 5% is not lost time, that 5% is being very
> optimistic and 'models' otherwise unaccountable time like IRQ and
> random overheads.
> 
> Thinking you can give out 100% CPU time to a bandwidth limited group
> of tasks is delusional.
> 
> Explicitly not accounting things that you *can* is just plain wrong.
> So no, Yuri's thing is not going to go anywhere.

The goal of Yuri's patch was not to avoid accounting things... The goal
was to avoid subtracting the fair dl server utilization from the
utilization reserved for real-time tasks (assuming that
/proc/sys/kernel/sched_rt_runtime_us / /proc/sys/kernel/sched_rt_period_us
represents the fraction of CPU time reserved for real-time tasks).

Maybe we made errors in describing the patch (or in some details of the
implementation), but the final goal was just to ensure that
sched_rt_runtime_us/sched_rt_period_us goes to RT tasks; the remaining
fraction of CPU time is shared by SCHED_OTHER tasks, fair dl servers,
IRQs, and other overhead (the fair dl server utilization can be smaller
than 1-sched_rt_runtime_us/sched_rt_period_us, so some time can be
explicitly left for IRQs and kernel).


				Luca



				Luca