From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 84FF836D4E3 for ; Tue, 3 Feb 2026 20:29:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770150593; cv=none; b=I/NzSgv87l6ioSh/8pMzmwYgP25pzn0JZCqerlgt301JARjvZpoxjfGv1Kd20qYpjqJbtcrCC5KmX5k042n0L4/MaOojMqt/ISqZGv5GhLjbZErIfnxm5X/RQFlU6Dl2m5ybVt5wk58afMbnyQBFxnLUAxcO5T4mkiijNSgc6rw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770150593; c=relaxed/simple; bh=pwAuydj+wHTQZXBRWRI8q3LJFAEfzhAzILzqt4om8jY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LVpnq6aqnv0kVLyB7tWbD1vZdotmiF9OLPZFjcnHPsEm8cz7ws5pQObHPeJIQsmNJDBWF9D5b2hT/74/0/eGWBzWktI+JQygFwcFP8QR0umvZdi08LmeQ3JnxxEFIjIDKcoo5n4hBILasqPoxKg5aVh6EjO5bOBFPi2Q2HWhAvM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GfbMmUtX; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GfbMmUtX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1E312C116D0; Tue, 3 Feb 2026 20:29:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770150593; bh=pwAuydj+wHTQZXBRWRI8q3LJFAEfzhAzILzqt4om8jY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GfbMmUtXn/6zI/WuFD+viBPkNpMnNdwRZtaQMOd27JdQJs1J1AItlemN3AAeItLhx SD9j9KQj6hx05nrj59FK06y9W0R9xPvhifhmOAWJmzmD+KVlVAs7aZamjwuU4gTUP5 iGokjQ8OPQgYhWIzD11KzGUdpxFt2u4eKMHyiR4QEmLB287pGwtIS3vRPqerE4Zg+1 SL2D/Mlg2UiF42AeFNZXsTOOsNCuovLpbifnSTyB/D5n79rv9G3VOPhKf7HX51hoEM X3mTJZTnXsed0j75jt+2fPi4cT+14wxnYKAZDchd+99kFmizueRxEPm4Wl4zQ74uhZ v0TnjjnZC3qhA== Date: Tue, 3 Feb 2026 10:29:52 -1000 From: Tejun Heo To: Chuck Lever Cc: jiangshanlai@gmail.com, linux-kernel@vger.kernel.org, Chuck Lever Subject: Re: [RFC PATCH] workqueue: Automatic affinity scope fallback for single-pod topologies Message-ID: References: <20260203143744.16578-1-cel@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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