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] [day] [month] [year] [list]

Message-ID: <aYJd46xHsiIgzOSs@slm.duckdns.org>
Date: Tue, 3 Feb 2026 10:43:15 -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

Hello,

On Tue, Feb 03, 2026 at 03:34:22PM -0500, Chuck Lever wrote:
> The patch addresses that, I'd hope, by only switching to per-CPU on
> single pod (ie, simple) systems. Larger, more complicated, topologies
> should be left unchanged. I imagine that on a single pod machine with a
> large number of cores, having per-CPU locking will nearly always be a
> win.

Oh, I mean, unfortunately, intel produces chips with a lot of CPUs on a
single L3 cache. e.g. Recent intel chips have upto 128 cores per socket and
each socket still presents as a single L3 cache domain, so falling back to
AFFN_SMT would mean that all unbound workqueues by default would be backed
by 128 pools per socket. Create some hundreds of threads per pool and then
now you end up with hundreds of thousands of kworkers.

Thanks.

-- 
tejun