linux-kernel - Re: [PATCH sched_ext/for-6.13 1/2] sched_ext: Avoid live-locking bypass mode switching

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: <Zyq5ZELbPjqIQ-Pc@gpd3>
Date: Wed, 6 Nov 2024 01:33:40 +0100
From: Andrea Righi <arighi@...dia.com>
To: Tejun Heo <tj@...nel.org>
Cc: David Vernet <void@...ifault.com>, linux-kernel@...r.kernel.org,
	kernel-team@...a.com, sched-ext@...a.com,
	Changwoo Min <multics69@...il.com>
Subject: Re: [PATCH sched_ext/for-6.13 1/2] sched_ext: Avoid live-locking
 bypass mode switching

On Tue, Nov 05, 2024 at 02:26:38PM -1000, Tejun Heo wrote:
> External email: Use caution opening links or attachments
> 
> 
> Hello,
> 
> On Wed, Nov 06, 2024 at 12:57:42AM +0100, Andrea Righi wrote:
> ...
> > Do you think there's any benefit using the idle injection framework here
> > instead of this cpu_relax() loop? At the end we're trying to throttle
> > the scx scheduler from hammering a DSQ until the scheduler is kicked
> > out, so we may just inject real idle cycles?
> 
> That involves switching to the dedicated task and so on, right? When this is
> needed, we can't even trust whether the system is going to make forward
> progress within the scheduler. I don't think it'd be a good idea to call out
> to something more complicated. Also, from forward-progress-guaranteeing
> point of view, cpu_relax() is as good as anything else and this shouldn't be
> active long enough for power consumption to be a factor.

Ok, I see, we want to keep it simple, because the CPUs might be
congested (like even from a hardware perspective), so in that case
cpu_relax() makes more sense probably.

Thanks,
-Andrea