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 CE0542DECDE for ; Tue, 3 Feb 2026 19:10:37 +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=1770145837; cv=none; b=FhGliTzzmyZ1hF57ENbHILMdRi+NAQssVUzukz9ogaLUScDHodP7WrlDHzCCTuAktN9dj9Sd2GWzPtkAdLm57SENP4oK/FS+CB8AZF+cVv8URwzXQRnU+SLglTCRoOV1rZCH9kGdbnVTFxw1ya577lUj0XoYhzanoqsRsvs90jk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770145837; c=relaxed/simple; bh=jwpUpAydCu97URoNNdN1qK6Z+TtDNZOrpDmWdoThP4M=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=SYZIQZ6vB3RsPpyadmrBY4mbZCYQXbok/Is9Otloau+IX9fB7x2IBPAyaT3gViwY66jXHlrfqqdnhiMocCTssEp8iWn23OSzVmll69LG88jeBs1/AYEB7KAqNNYwbZkjjpMaLvp8KPT3I0PCH35jqdmnHiPdAmg6Zhi25cH3b/k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ePcOPKRL; 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="ePcOPKRL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3BDE4C116D0; Tue, 3 Feb 2026 19:10:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770145837; bh=jwpUpAydCu97URoNNdN1qK6Z+TtDNZOrpDmWdoThP4M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ePcOPKRLTcFTIclFjFkm0bptHjDz5lKK9nb/HZw+lqgL4Ujm1pCmgfPGcbQVE9hSE 1tVF+ElyBAOjMNwLpJ4JV2YGR1pQGkc64nc+Iyy8PK6hBuJxomn2F7crVLQ5cc5jKK cgLB+MZh7ObfWtxuFgcYH+tm9145k+c8ImQ1ck3CT3vlNMrN4WQOq9QBQfOL8vBAqf xya0tE0+yEVoHWvpRLMheNoDqUHleyvhE0I0TtWRW658VIU908c0VMQOhTEr3XilNG Odz3nmziMUjRRcB43+JDhAO1ISNBFyrop5VPLIfWstB3pmCECrUVyOiCFyM6sRHVZ7 NlUNWbXFvnhoQ== Date: Tue, 3 Feb 2026 09:10:36 -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: <20260203143744.16578-1-cel@kernel.org> Hello, On Tue, Feb 03, 2026 at 09:37:44AM -0500, Chuck Lever wrote: > On such systems WQ_AFFN_CACHE, WQ_AFFN_SMT, and WQ_AFFN_NUMA scopes all > collapse to a single pod. WQ_AFFN_SMT should be on CPU core boundaries, right? > Add wq_effective_affn_scope() to detect when a selected affinity scope > provides only one pod despite having multiple CPUs, and automatically > fall back to a finer-grained scope. This ensures reasonable lock > distribution without requiring manual configuration via the > workqueue.default_affinity_scope parameter or per-workqueue sysfs > tuning. > > The fallback is conservative: it triggers only when a scope degenerates > to exactly one pod, and respects explicitly configured (non-default) > scopes. 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. Given that WQ_AFFN_CACHE is the same as WQ_AFFN_NUMA on these machines, maybe we can shard it automatically according to some heuristics or maybe we can introduce another affinity level between CACHE and SMT which is sharded on machines with too many CPUs in a single cache domain. Thanks. -- tejun