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 1806E373BF6 for ; Fri, 17 Jul 2026 16:25:18 +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=1784305520; cv=none; b=ttE7T7x+oxKh8KJp5c+/AJbV+B855Kc+pJHPwnCkiqX/Wr5X1dUwrVZpq6NBxgTz5TKsZe3ZpFgrN41Gp6SO/QM5tlBAANp30vg2piPaZ9aC17bxleD9EZdIv5Onq+a3LJMBZsFTKXtDyZg8aZL5aSGSMZbjv537XDQjpqjc5iQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784305520; c=relaxed/simple; bh=SlRuKUBN/xSIDjvzBRB+IqwT15hUD7ouwuTkhJAWJ0Y=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=H20wH/bxrSH+CqTNA9l6yO3S5Dzpaqndc4+MbjWpWBRcX7Heet5t+WEIiylb9IV7UVRjfPO7In+xyRqqWboYRVmc6NxLKaA+T4D4xPn88iqvn2s8TdB4yKwbqOkVe7TfFRO364MtKo1T100PoG0P3Dfmc08TMdqQ87ObrYRbUOQ= 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=ATL8T01m; 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="ATL8T01m" 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=Ao95FkoqG4AoLccKnXSz3z33B9Bi4AJSWFD7P/M7tcQ=; b=ATL8T01mmwTDIBpmN4RUibGWVx u13YEewhB3Gxir0q9IUZE38OROGvv3JT3UQ5tQKzpbYAU+uEPULPA1ozdrJRm/NHDQ6lf15EUxojd BOgm1FZq7PXR0IwuRTq8IqvCcFkIdkOy3OKdlGyrN0CAK+m0AFwnP2G8vNbYcucK0c2pLSf+QLn5z ayHJKnqUosYiMdVCVwxW/FdFW8yZYysvQenQyhiQaF+JNdHd0MFkLJds8vetEWuqO5RgW2Wtz7nHq LG7cu7IHHvrCBBc/usQACkj9hBVAq6HaL2TSozaHAhwl8Rop7NkTfBVlhA7jHe9wCbr5ErN+FqZJn f/DF3O/A==; 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 1wklNC-004j0K-0y; Fri, 17 Jul 2026 16:25:14 +0000 Date: Fri, 17 Jul 2026 09:25:09 -0700 From: Breno Leitao To: Tejun Heo 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: X-Debian-User: leitao On Thu, Jul 16, 2026 at 09:22:50AM -1000, Tejun Heo wrote: > Hello, > > On Tue, Jul 14, 2026 at 04:41:46AM -0700, Breno Leitao wrote: > ... > > 1) wqattrs is an unbound concept and apply_workqueue_attrs_locked() rejects > > non-unbound wqs. Should we leverage wqattrs in per-cpu workqueues as well, > > so the unification can happen later (apply_workqueue_attrs_locked())? > > I'm not sure adding wqattrs to percpu workqueues makes sense. Wouldn't the > shape more be like unbound workqueue subsuming percpu workqueue? > > 2) If percpu becomes a WQ_AFFN_CPU affinity setting, how should max_active be > > treated? WQ_AFFN_CPU is unbound today, so it would inherit per-node > > accounting (wq_node_nr_active) and lose percpu's per-cpu max_active > > (pwq->nr_active). > > I think it probably would be better to introduce a separate affinity scope > than modifying WQ_AFFN_CPU. Something which indicates that concurrency > management is in effect and max_active is per-cpu. > > > 3) What end state are you aiming for? Keep WQ_PERCPU as a thin flag over > > unified internals (single install path, per-cpu accounting special-cased) > > with WQ_UNBOUND staying for now -- or something more radical (the flags gone > > entirely, percpu purely an affinity value)? > > Keeping WQ_PERCPU as a shorthand for specifying the percpu scope makes sense > to me. Oh, now I see what you mean, I was heading the wrong way. Thanks for the clarification, that makes total sense. 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 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? 2) What about WQ_BH? Can we keep it on the direct per-cpu path (softirq context) for now? 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? Thanks for the guidance, --breno