linux-kernel - Re: [PATCH 04/13] sched_ext: Use per-CPU DSQs instead of per-node global DSQs in bypass mode

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: <aRIhUIcDnjrGIoJf@gpd4>
Date: Mon, 10 Nov 2025 18:30:56 +0100
From: Andrea Righi <arighi@...dia.com>
To: Tejun Heo <tj@...nel.org>
Cc: David Vernet <void@...ifault.com>, Changwoo Min <changwoo@...lia.com>,
	Dan Schatzberg <schatzberg.dan@...il.com>,
	Emil Tsalapatis <etsal@...a.com>, sched-ext@...ts.linux.dev,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 04/13] sched_ext: Use per-CPU DSQs instead of per-node
 global DSQs in bypass mode

On Mon, Nov 10, 2025 at 06:42:56AM -1000, Tejun Heo wrote:
> Hello,
> 
> On Mon, Nov 10, 2025 at 08:42:47AM +0100, Andrea Righi wrote:
> > On Sun, Nov 09, 2025 at 08:31:03AM -1000, Tejun Heo wrote:
> > > Change bypass mode to use dedicated per-CPU bypass DSQs. Each task is queued
> > > on the CPU that it's currently on. Because the default idle CPU selection
> > > policy and direct dispatch are both active during bypass, this works well in
> > > most cases including the above.
> > 
> > Is there any reason not to reuse rq->scx.local_dsq for this?
> ...
> > > The bypass DSQ is kept separate from
> > > the local DSQ to allow the load balancer to move tasks between bypass DSQs.
> 
> This is the explanation for that. More detailed explanation is that local
> DSQs are protected by rq locks and that makes load balancing across them
> more complicated - ie. we can't keep scanning and transferring while holding
> the source DSQ and if the system is already heavily contended, the system
> may already be melting down on rq locks.

Ok, thanks for the explanation, makes sense and it's definitely better than
what we have right now, so:

Reviewed-by: Andrea Righi <arighi@...dia.com>

-Andrea