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 A78163F787F for ; Fri, 8 May 2026 15:11:09 +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=1778253069; cv=none; b=BBqOHGL2Um3gGEAGFpyqI2HTmHwQntiHo95bNWnTnz6ga9tJa3n0Ch9VJv2p9HPaxjxCjJ20mryyuAN0xhfg3ECJrRf7gyNlDI6NrY85l+wjwyRAgorL48AElu9mr2xQrYCZR/hlGK0nmzeOM4+YOaYNatZ3Y9sYEMRx4oLtFJI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778253069; c=relaxed/simple; bh=VIIiK5IJYsTFUIgIBkqgCvz2E2GlBEMTlUd/aKjO6u8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=eQmeNIcgynAGDo1bvIz5T1zOrM73Iy3vlk99TxmVdvw16dC3errwdYEghIM50BXDUrcTnuubvzp1bdVzrjbAvuc3JG7mRY49uYM7+8A4j+RyEEqXKXtQMOUBmdTpj8agEnWrdIFT4Gc6aQZOuJjx+uJHNV1qGT87obVqRcbWQ/Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YXYdOxaM; 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="YXYdOxaM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 17306C2BCB0; Fri, 8 May 2026 15:11:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778253069; bh=VIIiK5IJYsTFUIgIBkqgCvz2E2GlBEMTlUd/aKjO6u8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YXYdOxaMjRYkT1gjfzO8m0j7g1T5eSdbybwo9l0sz3MdTCiDsxQ6sgVZigDvAPT4K 7UsqmcnS/DsIDJwXNAF5l6UK68Gy/RqbpHDjH0xqR+t9W0ebnISfT+xcQu3DZMrVCY IgYTfGH/8FSftZEimI2v2nEUJGuad/43cSpB6KERd0xw08o1iSifOohtcw5IsWyVGG QA6Tacg98/pZgYdTHr/BgfMB20JWBC9pgzfSXCgcYxmhYwecEN4jruFqyt9kb6xeSS l0pebKlcwKsLywf0HXLdqfhsqLevRcrGp0OmyYo5wGmKLnAYTmsrkS7fDXKR7RvmJo cWWl7+diFCUrw== Date: Fri, 8 May 2026 05:11:07 -1000 From: Tejun Heo To: Frederic Weisbecker Cc: Marco Crivellari , Breno Leitao , linux-kernel@vger.kernel.org, Lai Jiangshan , 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: Hello, On Fri, May 08, 2026 at 02:09:20PM +0200, Frederic Weisbecker wrote: > Isn't WQ_POWER_EFFICIENT enough for what we want here? ie: it does a per-cpu > preference except when some config is enabled or isolation is on. It could be > renamed to WQ_PREFER_PERCPU to generalize its meaning for more than just power > purposes. That may satisfy the minimum requirement but I think it'd be a shame if we do all the work and still leave the semantics overloaded, which was the initial problem to begin with. I really want the intent of each specific selection expressed unambigiously. Besides, even outside of isolation use cases, having relaxed affinity can be useful as it gives the scheduler more leeway in placement decisions. e.g. There's no real downsides to running such work item on SMT pair or maybe that CPU is particularly overloaded due to net irq and rx processing and some work items are better off running on another CPU in the same LLC and so on. If we can manage so without causing perf issues, I want the default to be soft affinity, not a hard one. Thanks. -- tejun