From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from stravinsky.debian.org (stravinsky.debian.org [82.195.75.108]) (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 2CF503803D0 for ; Mon, 3 Aug 2026 16:35:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=82.195.75.108 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785774928; cv=none; b=JvLlqto9TlVMrxwaYxVlKdkh0Exa7Mt7yM3djQYE6m7Svyowoe/iXKmqRdjgfI7DnYpE/GDCvsTBMuvNnbmtsWopfxlUwOLQaB+zPZR4XHk0nLqaQyZautXqgNoPtg5/SWsuFXWpctmNUqFZMGqEt4Bo7Q1a0xT2kOdi8fGAqFY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785774928; c=relaxed/simple; bh=/o87M96V44Ofei4jwQsppxmF0cWalQmgjydvMuC8AGc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cDXC4SFkFpZW95tmBEZKPHg4rUMLKzC1gbb6hWkhrPNpnCYgroXLxiLi2JMsJIPW4SpAPB2/Vir83d4dTHL+67k96o7YOquvQKzrFXGzRyOQ7NBcFP/ZV5jGD14LO0HJn2YTG4KlLZxB0ZPeNMU+2UvMeSmDCjinkvYjDSvb2ho= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=debian.org; spf=pass smtp.mailfrom=debian.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b=FYMv5VnF; arc=none smtp.client-ip=82.195.75.108 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=debian.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=debian.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b="FYMv5VnF" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=kEr1D7sN3mvgDYqM0ma5VIHDiQhkYlcC1mgINx+2h+k=; b=FYMv5VnFcDccyd98nDlf8E013v vv6Lu/1bHYBtQGcgAyZtoBrGJBfev92oEx0HQsllwV7QUDMc9uCh3cV3HM7hC9r9OZd2/4o3UNwmS Y9JqezkD18akwCSppL3nmWeTgPs333Vhc8nJHxiweuzkrdYpXHl1w/DyZg1H/hLPEHLMjRPS34HAa zq2u0j2E/FnIgXCUN/uiJGQ2JmKKkI1v46rdXoz0g7jn1KWEMLh8QkT6LpbuXSmAILpJjyQHQ6LfV ijwoekyzaIMRE6e7BgY0w4slPDDbucv82PYxzRV9F16LxoiKVUOvM7eCvVcn9JqywYgfawiRsHVV+ jUdvRfow==; Received: from authenticated-user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from ) id 1wqvdJ-00CUnW-2B; Mon, 03 Aug 2026 16:35:22 +0000 Date: Mon, 3 Aug 2026 09:35:16 -0700 From: Breno Leitao To: Tejun Heo Cc: Lai Jiangshan , linux-kernel@vger.kernel.org, kernel-team@meta.com, marco.crivellari@suse.com Subject: Re: [PATCH 5/6] workqueue: add a per-cpu backend for unbound pwqs Message-ID: References: <20260731-wq-pool-refactor-v1-0-8eaf71cdab5f@debian.org> <20260731-wq-pool-refactor-v1-5-8eaf71cdab5f@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: X-Debian-User: leitao On Sun, Aug 02, 2026 at 02:36:52PM -1000, Tejun Heo wrote: > Hello, > > On Fri, Jul 31, 2026 at 04:57:37AM -0700, Breno Leitao wrote: > > Add alloc_percpu_pwq(), which binds a pwq to get_percpu_pool(wq, cpu), > > and an internal __WQ_PERCPU_POOLS flag. unbound_wq_update_pwq() installs > > such a pwq per CPU when the flag is set, reusing the existing > > install/drain path. Pool release and nr_active are already keyed on the > > backing pool, so a per-cpu-backed pwq is torn down and throttled > > correctly. > > > > PS: We can do this using if/else for per cpu/unbound as well, instead of > > this labels:, would it be better? > > So, we would have percpu-pool backed unbound workqueues in addition to the > existing percpu workqueues? I'm not sure that makes sense. What prevents > unifying them? Nothing fundamental. What I'm working out here is how to plug the unbound pwq machinery into the percpu pools, and I came up with this __WQ_PERCPU_POOLS. I am trying to following what you said here: described in https://lore.kernel.org/all/ak569WYSm3ygKl1-@slm.duckdns.org : > [...] just merge percpu and unbound workqueues. Unbound workqueues > already have the ability to update pwqs (or rather install new ones and > drain old ones), which is how attribute changes are implemented. If we > make the pwqs be able to point to both unbound and percpu pools, the > dynamic switch falls out naturally and percpu just becomes one of the > affinity settings. This is the design I am trying to convey to, please let me know if they are not correct. a) There is one workqueue implementation -- what is today the unbound one -- and percpu becomes one of its affinity settings rather than a separate type. The unbound_* helper names get renamed/removed once they stop being unbound-specific. So, `alloc_unbound_pwq()` becomes `alloc_pwq` and handle both cases. b) There is one pwq path, and alloc_and_link_percpu_pwqs() goes away. c) Which pool backs a pwq becomes a property of the attrs, resolved in alloc_unbound_pwq(), which hands out either the static percpu pool for that CPU or a hashed unbound one. d) Both pool types stay -- concurrency management only exists on the percpu ones -- so what gets merged is the machinery, not the pools. e) this ugly __WQ_PERCPU_POOLS goes away, WQ_PERCPU carries the intent, and the unbound path handles WQ_PERCPU directly. WQ_PERCPU and WQ_UNBOUND stop being mutually exclusive types and become a choice of backing, so the exclusivity check in alloc_workqueue() changes meaning or goes away. Thanks for the guidance here, --breno