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: <aRIWEBDmjxScAsyP@slm.duckdns.org>
Date: Mon, 10 Nov 2025 06:42:56 -1000
From: Tejun Heo <tj@...nel.org>
To: Andrea Righi <andrea.righi@...ux.dev>
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

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.

Thanks.

-- 
tejun