linux-kernel - Re: [PATCH v2 3/2] sched/deadline: Check bandwidth overflow earlier for hotplug

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 for Android: free password hash cracker in your pocket

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

Message-ID: <Z62PPUOY5DClYo1A@jlelli-thinkpadt14gen4.remote.csb>
Date: Thu, 13 Feb 2025 07:20:45 +0100
From: Juri Lelli <juri.lelli@...hat.com>
To: Dietmar Eggemann <dietmar.eggemann@....com>
Cc: Christian Loehle <christian.loehle@....com>,
	Jon Hunter <jonathanh@...dia.com>,
	Thierry Reding <treding@...dia.com>,
	Waiman Long <longman@...hat.com>, Tejun Heo <tj@...nel.org>,
	Johannes Weiner <hannes@...xchg.org>,
	Michal Koutny <mkoutny@...e.com>, Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
	Valentin Schneider <vschneid@...hat.com>,
	Phil Auld <pauld@...hat.com>, Qais Yousef <qyousef@...alina.io>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	"Joel Fernandes (Google)" <joel@...lfernandes.org>,
	Suleiman Souhlal <suleiman@...gle.com>,
	Aashish Sharma <shraash@...gle.com>,
	Shin Kawamura <kawasin@...gle.com>,
	Vineeth Remanan Pillai <vineeth@...byteword.org>,
	linux-kernel@...r.kernel.org, cgroups@...r.kernel.org,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: Re: [PATCH v2 3/2] sched/deadline: Check bandwidth overflow earlier
 for hotplug

On 12/02/25 19:22, Dietmar Eggemann wrote:
> On 11/02/2025 11:42, Juri Lelli wrote:

...

> > What about we actually ignore them consistently? We already do that for
> > admission control, so maybe we can do that when rebuilding domains as
> > well (until we find maybe a better way to deal with them).
> > 
> > Does the following make any difference?
> 
> It at least seems to solve the issue. And like you mentioned on irc, we
> don't know the bw req of sugov anyway.
> 
> So with this change we start with 'dl_bw->total_bw = 0' even w/ sugov tasks.
> 
> dl_rq[0]:
>   .dl_nr_running                 : 0
>   .dl_bw->bw                     : 996147
>   .dl_bw->total_bw               : 0       <-- !
> 
> IMHO, people who want to run serious DL can always check whether there
> are already these infrastructural DL tasks or even avoid schedutil.

It definitely not ideal and admittedly gross, but not worse than what we
are doing already considering we ignore sugovs at AC and the current
bandwidth allocation its there only to help with PI. So, duck tape. :/

A more proper way to work with this would entail coming up with sensible
bandwidth allocation for sugovs, but that's most probably hardware
specific, so I am not sure how we can make that general enough.

Anyway, looks like Jon was still seeing the issue. I asked him to verify
he is using all the proposed changes. Let's see what he reports.

Best,
Juri