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 681DF57C9F for ; Tue, 3 Feb 2026 20:43:16 +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=1770151396; cv=none; b=tt6Ap057DAVkkxaUUe+5183Z+Q3YsjMKo7rUiDtbEQ30xdItfkF2FagPEmeK5WiVEwNgRq3pNGujYoiB76uGM7Vz5E75a5RYCVKFnNlNcdvowPj4WEF5/qgEi1PR+ciAAjn/C8h3KzGaRSdN4oPbs8xkLSu/t2mTHAjE3WzGS84= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770151396; c=relaxed/simple; bh=Bp85Iqbx4hXtx8MW3WquoqZ+Lm7gQOFES3nOerMQjHo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=r4md6E3qC0myX9wbgcGMgbQsuwr5I7SopMNqZgsk+0aHTDk+wS9JdA1eFoKR80iacR2NdhLhulOkSzVQD5ArbJbvxYZbFHiw92T4YHPHIblBLy9vurP8mqB12dS5ehf59AK5eOWcxa1ChlqAUmuUDrDk1keT+MX4xTaizLqUzTw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=StVXv2Sy; 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="StVXv2Sy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 16BB2C116D0; Tue, 3 Feb 2026 20:43:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770151396; bh=Bp85Iqbx4hXtx8MW3WquoqZ+Lm7gQOFES3nOerMQjHo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=StVXv2SyUMvMyBWPYFFMcMaPaUjnF5L+qLxpWX3LwWNBz6m46ifA8UDM0/XIv1eFA Ff8m05WNEAfjkkuCmbXrChglY16cZhwDrCWGuMgka4m1pvraNdkK1jGNZXPba3Ym2F 5Mya00SGJy9ogJg/ski0WzCo6Z3fx3d4tPgKSECkpl8/4qF1r888I18NYPJy54JVum o8m4laL40C3ZrUDXDQZtrTqfJMshauxsE9PXrOEGNIRq5FAq9J6Of0vD46h9YHYFsM g/R1o4RvGv1cJOI9Z9kKt+gRQqVwb/0oVXlnmjV0z8FBa6YG/Ap+xCd113MwtD3pky CspmuW6jwOIrQ== Date: Tue, 3 Feb 2026 10:43:15 -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> <8e66cf1a-09e2-4261-b2b4-6a5e608b9ec7@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: <8e66cf1a-09e2-4261-b2b4-6a5e608b9ec7@kernel.org> 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