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 4E4AE37B014 for ; Tue, 5 May 2026 20:18:51 +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=1778012331; cv=none; b=e6NPLy+2pj1pDgOaVLE+u+XqP3MnbRXc5AWxFRthT8R3Z7FXjTyVN2mT+NV45fmE+KEPeDPaQ7NuhmF3JQGY7Txz28gMkr9mJV6baGpKLgFWbI0bxD2IghgXKAhO5xStJXVvOEZ7N+XO3/45+PLwCJ4l3GuPD/7O04VwUZV1GwI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778012331; c=relaxed/simple; bh=RD+lDupoxvVmvzsdhW8aW6/iBvw3sduv1NgDELSWHRI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=X+H3AbML3HvnogQTgiNJFbsjRD7GRz3QYQqAXtZcSPJN6mU0P2NhqRxBcV88kRH4esKuZNPQdUhd6iKUuog6VtG+yN07etiJhogPXxKHHbOxmmMhf2yYcH7S1xCkk3Qzw0SlaqAz+MzCBxHt7CosiKmm7O3H6uvQu/S6WjMlUD4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=txHRHIZC; 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="txHRHIZC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D7B07C2BCB4; Tue, 5 May 2026 20:18:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778012331; bh=RD+lDupoxvVmvzsdhW8aW6/iBvw3sduv1NgDELSWHRI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=txHRHIZCHC356946qRdQS+y/m7/hd2dk434g1JBI8ylbU/0MCMvyPe94me0k0481N DQrLDPTwg66Qk4gD+RhrvmsINA+OpyVacBGI5sEwKddGENCszys2Exr/1N4F89uJHD ag539CffXBQJuenwOtwVKv7c2J+kyQKWJXYiW0/TU1EdqsFoXfKtxQbqTxGy3+z1Wf Q/XC2zP7O1AomXYa2yzIK6di/T+rtuqww74ExgGNnzmzuWb18KY34zE8cdjVD1FaTM TG5mF4c1Q142y3ObjNAr+OMJ6nmR/uCeg+KUOdmkDM5ZhG2XTxCwv7nmBDBv7WADTc IwZ6ciBHTf91Q== Date: Tue, 5 May 2026 10:18:49 -1000 From: Tejun Heo To: Marco Crivellari Cc: linux-kernel@vger.kernel.org, Lai Jiangshan , Frederic Weisbecker , Sebastian Andrzej Siewior , Michal Hocko , Breno Leitao Subject: Re: [RFC PATCH 0/2] Add queue_*() functions and prefer per-cpu workqueue and flag Message-ID: References: <20260505161658.401998-1-marco.crivellari@suse.com> 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: <20260505161658.401998-1-marco.crivellari@suse.com> (cc'ing Breno) Hello, On Tue, May 05, 2026 at 06:16:56PM +0200, Marco Crivellari wrote: > Actually schedule_work() and schedule_work_on() enqueue works using > system_percpu_wq. The function name doesn't suggest it, on top of that, > only the per-cpu version is present. I was hoping to just retire schedule_work[_on]() and let people use e.g. system_percpu_wq directly. Is that too verbose for casual users? > Because of that, the following changes are introduced: > > - queue_{bound|unbound}_work() as future replacement of schedule_work() If we do this, I think "percpu" is a lot clearer than "bound". percpu <-> (nothing) combination would be nice eventually but maybe that's too confusing now. Does percpu <-> unbound combination sound weird? ... > The Workqueue API currently do not distinguish between use case where > locality is important for correctness and where is important for > efficiency. So introduce WQ_PREFER_PERCPU and wq_prefer_percpu_wq, so > that works who need to be per-cpu but don't strictly require it, can > use such workqueue / workqueue flag. What's requested through WQ_PREFER_PERCPU is simliar to what WQ_AFFN_CPU does, so that might just work out. The only problem is that WQ_AFFN_CPU will create nr_cpus workers to populate the per-cpu pods on boot. Maybe that's not a problem if this gets used widely. Thanks. -- tejun