linux-kernel - Re: [RFC PATCH] workqueue: Automatic affinity scope fallback for single-pod topologies

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: <aYJawDy77Mxu9SZA@slm.duckdns.org>
Date: Tue, 3 Feb 2026 10:29:52 -1000
From: Tejun Heo <tj@...nel.org>
To: Chuck Lever <cel@...nel.org>
Cc: jiangshanlai@...il.com, linux-kernel@...r.kernel.org,
	Chuck Lever <chuck.lever@...cle.com>
Subject: Re: [RFC PATCH] workqueue: Automatic affinity scope fallback for
 single-pod topologies

On Tue, Feb 03, 2026 at 03:14:46PM -0500, Chuck Lever wrote:
> > While I understand the problem, I don't think dropping down to core boundary
> > for unbound workqueues by default makes sense. That may help with some use
> > cases but cause problem with others.
> 
> I've never seen a case where it doesn't help. In order to craft an
> alternative, I'll need to have some examples to avoid. Is it only the
> SMT case that is concerning?

It's just a lot of separate pools on large machines. If you have relatively
high concurrency, the number of workers can go pretty high. They'd also
migrate back and forth more depending on usage pattern and have worse cache
locality. Imagine you have a bursty workload wandering through the system,
if you have nr_cores pools, it can easily end up with kworkers > nr_cores *
max_concurrency.

Thanks.

-- 
tejun