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 9D8FE3FE353 for ; Wed, 6 May 2026 13:40:08 +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=1778074810; cv=none; b=twsajf2KB7MQpSR450TTjLCQRwxuPLxBbk2XufDy8TkKhCjWIxpPZyqZ+drWhkBr7vEJ2jzOp9hSfOz3W6dEDjDSfyQsLEMo158hdknOCNmQshmBsVRfrqF5IeH6E9Al5Ftc/vos9p0jlJVhub3KjWRPLCzamzqkXI3riUJbSjY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778074810; c=relaxed/simple; bh=3upThqMhsLx4lksZIOVdz11KH496wD3jVwReSWcTG1I=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=G6wvMDNgPZ7R3azhKU6FN25J7494rpHAgqwx2JCOSLrG7QJrBh+GZI9xQlVHC+7LjBt84daFK2QKCJsJURlcGh8NDzudak3cWSe+PkxRylLXCs3Fr4cC7i4RQA1f9sCCYeJu5YVP1TYvjkdjlEaYEzQFSFwmVpIaRpGPU/FVDRI= 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=q1FKv5kH; 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="q1FKv5kH" 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=sinZiX9tDRCb23YecwHyWXVOVYT/E+1a5goTJ96A080=; b=q1FKv5kH2IRodqXKiM+CU0ZyLS FbdVlIilpCEpAvf8Rr933zYic1kweEsG2OtvGb/2i5BDYwQzQWB6xebw4s+NJRQG06LTy2YYQ3blo ufbF5ZlHXuD0IbkC4g1iIcylwuwUr3/X8kUMBiYbmLBxyS2p+4X40DVAYQc3sGP/MvK3bF3ALQOiM AgQwFpz5Hz87nfO53aBvphVS9QqFGFVeVFvU+wku6JKiAsnrwU5BDfL4+r4nEs79u4BfOyxT+7Xcv DZAmxt8l1QlN6aTFYGwE1g8Zj/Kxkld6gi7xqrFpFvpm3ui4AE2zVaE2E3mW4gy49ux7mVtwOy4re kguZa2PA==; 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 1wKcTt-003d2a-2W; Wed, 06 May 2026 13:40:06 +0000 Date: Wed, 6 May 2026 06:40:01 -0700 From: Breno Leitao To: Tejun Heo Cc: Marco Crivellari , linux-kernel@vger.kernel.org, Lai Jiangshan , Frederic Weisbecker , Sebastian Andrzej Siewior , Michal Hocko 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: X-Debian-User: leitao On Tue, May 05, 2026 at 10:18:49AM -1000, Tejun Heo wrote: > (cc'ing Breno) Thanks! > 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? I think schedule_work() doesn't help much, and makes the system a bit harder to understand. When I started reading this code, I would have preferred to see queue_work(system_percpu_wq, work) instead of schedule_work(work). In fact, I suspect this patchset exists partly because we have the schedule_work() helper. Would this proposal exist if schedule_work() had never been added? > > 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? Would percpu <-> global sound less weird? > > The Workqueue API currently do not distinguish between use case where > > locality is important for correctness and where is important for > > efficiency. If you enqueue work to system_unbound_wq with the default affinitization, you already get locality (WQ_AFFN_CACHE groups CPUs sharing the same LLC). This is the way to say that locality is important for efficiency, anbd the WQ_AFFN_CPU is the way to specify that locality is important for correctness. On top of that, WQ_AFFN_SYSTEM is a way to specify that locality is not necessary at all. Also, how WQ_PREFER_PERCPU behaves differently from WQ_AFFN_CPU? Thanks for the RFC, --breno