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 0506540F758 for ; Mon, 3 Aug 2026 14:02:54 +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=1785765776; cv=none; b=t9m+J920B05mKt0l3QUwddQD9d/A87iKMuALbvzVkf8rv09dmYLLPV7d1YsF+ySIxB+NHeFsnwluTxpJLeYneyYSsr3z9nbDgYUe+cSwHBumS0Zp7XVDjZTn+qlCYLEX0EhKPVw2qjP6lavODIhvqyakmcioKtYDo2ZsexufSKc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785765776; c=relaxed/simple; bh=ykLxR3wcFtCaPzn6xEGajFtss3uA9y8s1kJbOwfjwzw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gHHB97UdjeYJeaDpBNVG3qxtYPW64ANqBPDNowvPqlMUaLxC3gynrW5PefXySQhFB6Q+0yIyJBSsv9JAAyCxJQuKY+CJW2LomQ8TAgPIx9qMU1LH8ifQuu5DvSAsNVDiUDyeePZNQ5Y0sUndVHdMZu5XYZOeiAubdg4klM+Z3CA= 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=TqFLueGP; 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="TqFLueGP" 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=RmLb00TB/n0jfbONPkemlLaesiNY2N3oq4iRforgHMg=; b=TqFLueGPZNdK130W5eUEEorYCg El4Ii6pWXU63QjTEx3Yfc5Aj/D3odwUzi/WH16VEHQF3dMB0QtGN551EX095StNbrGw5Ug7kXvnck a03zx/2dQ9GCXJB7jRWdP0SZc2+DSkhw1XoOIN+geizU2pgTLNtH7U9zeH8xk9ztw2RBz/aOg5wjE fKRgS30z6TkQIQTIy9zdxZ5b79iRxxCDOnSD6TBUJgo8TMrxmJuKWnrWSk0OXIXFmrBBTof5ia8wE jqLs/4+/F0P/ROjC1juCvXn6b3PAaQsSz07RUdpyywdgDQNvJP18R6AaPgcupRgkjcpvNe6S07IyI nuUCbvgA==; 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 1wqtFi-00CPUq-0t; Mon, 03 Aug 2026 14:02:50 +0000 Date: Mon, 3 Aug 2026 07:02:46 -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 3/6] workqueue: release pwq pools by pool type Message-ID: References: <20260731-wq-pool-refactor-v1-0-8eaf71cdab5f@debian.org> <20260731-wq-pool-refactor-v1-3-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:31:27PM -1000, Tejun Heo wrote: > On Fri, Jul 31, 2026 at 04:57:35AM -0700, Breno Leitao wrote: > > pwq_release_workfn() calls put_unbound_pool() based on the WQ_UNBOUND > > flag. That works today because an unbound workqueue only ever points at > > unbound pools, but the flag is the wrong thing to test: what matters is > > whether the pool is a refcounted unbound pool or a permanent per-cpu one. > > > > Add is_pool_cpu_specific() and key the release on it instead of the flag. > > This is equivalent for every existing workqueue and stays correct if an > > unbound pwq is ever backed by a per-cpu pool. Convert the other > > open-coded pool->cpu type checks -- in put_unbound_pool(), > > pool_allowed_cpus() and the workqueue watchdog -- to the same helper. > > > > No functional change. > > The first para saying that it's testing something wrong and then the patch > not having any functional change reads odd. Can you please rewrite? Fair, I meant that the two conditions agree today and nothing changes here. I will get this better. > > +/* True if @pool is tied to a specific CPU, rather than an unbound > > pool. */ +static bool is_pool_cpu_specific(struct worker_pool *pool) > > I'm not sure about introducing a new term. Can we just stick to > percpu? Sure -- is_percpu_pool() any better? Thanks, --breno