From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 48C244457A3 for ; Wed, 22 Jul 2026 18:56:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784746573; cv=none; b=HX74MWJlx7ZB2CI0zoa9apDzKM7AF1LyhxU9B4R7GBpuQSLVdokTf6WE9f7REzU4SxiXPJrJut9Dfqgog/3tbXpRKq5Xx7lMkClCnNHfo01J9NdLFob4GbG6FfKDdOxidnI8tumq4iXLy33l86qykLYvSP+oTM5obPF24cglMDI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784746573; c=relaxed/simple; bh=ImRU1XZ9bIaoRikKcVHvMSkR1PAXa8oJtg+FUBPfhvo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qDK9y50lK/vjnn8v87x0bYSiKcL7XbPA6wpZxh0NcnNNDLnDCPs2Zgs6m36oIMhPrzYGn5KNlT6GSIpWL460HL8DviKbaFMs0QV1N377Frc1dTxMTQk/IdjvNMTl6obJb6COC8/hmvd2ilY8R4Xq2uYM+dYia38Wn2X7M5m9UUA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VVa7id7Q; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VVa7id7Q" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AFE501F000E9; Wed, 22 Jul 2026 18:56:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784746571; bh=hWFyvNQx4fwbmmYNJrF/ipJ3vamsZDbvIrSRAW4emOA=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=VVa7id7QrJduSch2dmJS1e8DkLHjDIyJFTAJFOZV+KfkPeYLeaLyqiOEaxjCZlHye f02SHvGBOU2tjYoFPIBw8tOZ0YiIAHfCO/x2bf+U9iK8/yHWvP73eKOszvNP6o+Fi/ /f3/GFyUqink4UL7OMV3sFQ2Q6jL1Giwq2C3Xt+mJY9eRE0CeBOWLYFCRaCmyXW8MO iXtp2ld58krkdKhojvJEVWXIlcC+6ScbtY7buufjaxxCAC/zlSs3EtiwhcF/TLof8N qce42mTc0lzshfmAhpWyADqLPF42kdyDOoJzvfDDXE4RRmp/+U44tBFHL+/mhm4EEc fVI3Gs6F0YMmA== Date: Wed, 22 Jul 2026 08:56:10 -1000 From: Tejun Heo To: Breno Leitao Cc: Lai Jiangshan , linux-kernel@vger.kernel.org, marco.crivellari@suse.com, frederic@kernel.org, kernel-team@meta.com Subject: Re: [PATCH RFC 0/3] Refactor the workqueue allocations Message-ID: References: <20260714-tejun1-v1-0-024d59241386@debian.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: Hello, Breno. Sorry about the delay. On Fri, Jul 17, 2026 at 09:25:09AM -0700, Breno Leitao wrote: > So: add a PERCPU wq_affn_scope and back it strictly per-CPU, rather than > reusing WQ_AFFN_CPU. Something like: > > enum wq_affn_scope { > ... > + WQ_AFFN_PERCPU, /* one pod per CPU, backed by the per-cpu pool */ > > and move the per-cpu workqueue users onto WQ_AFFN_PERCPU. With that, the > unbound install path (apply_wqattrs and the per-cpu, replaceable pwqs) can > point a pwq at a per-cpu pool, so one mechanism serves both. Then move > all the WQ_PERCPU users to WQ_AFFN_PERCPU, and eventually deprecate > WQ_PERCPU ? I don't think we'd deprecate WQ_PERCPU. It'd remain the way to specify on creation that the workqueue has to be WQ_AFFN_PERCPU. Also, maybe WQ_AFFN_PERCPU can be more descriptive - WQ_AFFN_CPU_CM for concurrency-managed CPU scope? Or maybe this shouldn't be packaged into WQ_AFFN but rather become its own mode field. > I have this working as a prototype: WQ_PERCPU selects the scope and forces > strict affinity, and it boots with every percpu wq created through the > new path. > > A few things I'd like your read on: > > 1) Percpu workqueues keep the WQ_PERCPU flag (I don't switch them to > WQ_UNBOUND when they move onto the WQ_AFFN_PERCPU scope), so per-cpu > accounting falls out of the existing !WQ_UNBOUND checks. do you > have any preference here, or should percpu become purely an > affn_scope value with accounting decoupled from the flag? For concurrency management to work, it would need separate accounting (of max_active, right?). WQ_PERCPU would indicate that the wq must stay per-cpu for correctness, and we'd also want to allow concurrency management to workqueues which want to be percpu for performance reasons but can be switched into other affinity scopes for isolation, so it should move together with whether the backend needs concurrency management or not instead of WQ_PERCPU expressed at creation time. It kinda sucks that max_active's meaning is different across the boundary tho. Maybe percpu max_active should be separate into its own field, idk. > 2) What about WQ_BH? Can we keep it on the direct per-cpu path (softirq > context) for now? We can't switch workqueues on / off WQ_BH, but it'd also look a bit silly if this becomes its own path. Code-shape-wise, I suspect it'd be cleaner if this also becomes one of the pwq backends like the other two cases but that's just a gut feel. > 3) Routing percpu through apply_wqattrs pulls in unbound-only assumptions > (unbound_attrs allocation, and the CPU-hotplug fixups in > workqueue_online_cpu()/workqueue_offline_cpu() that gate on > unbound_attrs) that now have to learn about the percpu scope. > > Do you prefer teaching that shared path about WQ_AFFN_PERCPU, or would > you rather percpu keep a lighter install path (closer to the current > WQ_PERCPU direct path), if that's feasible? Again, without thinking too deeploy about it, I think the code would look better if we unify everything we can. Thanks. -- tejun