From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 39A9F382371 for ; Wed, 24 Jun 2026 19:46:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782330418; cv=none; b=uyOxVMoZKlIQrCz1Bpe2qaCdnA43ZerYQ57My6h3iCwMgZVX2XsxDGHWEC/sdLjESgKYcVaNPJhBmqp5puuqMA+ZoROjsWDX28nGkGZoVjB/dUcFONnAYoydfa+DWI1NtVsGs3gnaY0GLCR9P5Nv9mu1yxMKUQmx32UeuTMPUWw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782330418; c=relaxed/simple; bh=dOb2tnBGQWigAhITBnj2m0aYswg+3+Ts0JqG6YGRkYo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=EsmqHCC+99/EK5mDBIzYu4/V1v7fWqt5XB7SrSrLsSYaM497iG0OiO+yvsW9fMylW5jQJFanetPkFKR4Xmv01jdt6PFMKcUGMwfzOJT9pLRAvYmy2Fh66J6KGM44dqezJgEZ5dQVGCiOAHjRQ7DIDnx3VHiumrPVhHcwMaWrwik= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=e64YRWfg; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="e64YRWfg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9DFEA1F000E9; Wed, 24 Jun 2026 19:46:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782330416; bh=qBCoS4xf6Lrz3Qwg0GTPxM/008MRxQ8OOkFDGrDwme0=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=e64YRWfgNbEp8G8/EBRqY6Eo/oVvq1+GshS5c/a+lfiVwvj+tuMpbmM+fEC2uN2oI ELHo1vq3FvYEpCdKYttsZf5ubh/VZX5EFdBK5Qk//tT+FxahQmDyT4GeqBDfNmZb8y 7HQqIYQxOzCopqa0HMqk8f80uQQg9HjMWZB5XdHnqeGm8Y10JG/2ut2IwOJpV7L3uB zQJ/Jy48kGccdD2Fmo+7yWGAlJF9VcEwzfWxvMV8RKszpwpfju4/WWQcShMEDoN0Hl EwKnPM1tZrmVZBHvFGwuogfOasYf+3CwmmkhJhD7SkswIUdgl5w56TWCKKLZS5Fh7f gOBQTYdgsQGiw== Date: Wed, 24 Jun 2026 09:46:55 -1000 From: Tejun Heo To: Marco Crivellari Cc: Breno Leitao , 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: Hello, On Tue, Jun 23, 2026 at 05:13:31PM +0200, Marco Crivellari wrote: > > - At boot time, allow selecting whether to back them with percpu wqs or > > WQ_AFFN_X unbound ones. Maybe we can even experiment with default to > > WQ_AFFN_CPU. > > You mentioned here "at boot time". What about making this also dynamic, > "moving" the WQs with WQ_PREFER_PERCPU away from CPU N when N is > isolated through a cgroup isolated partition? Yeah, being dynamic is better but switching dynamically between percpu and unbound workqueues feels like it's going to be complicated. I can't think of a simple way to do that. If you can, please be my guest. > I considered checking the flag inside __queue_work(), checking the > isolated CPU mask to see if the CPU is unbound, and then choosing a > different CPU accordingly. > > I'm also wondering: when an isolated CPU is added / removed, should we > also act on the work items waiting in the worker pool? > Should the worker pool be DISASSOCIATED when/if only work items queued > with WQ_PREFER_PERCPU are on a CPU being isolated? I thought about > this, and because the worker pool has a list of items queued by > per-CPU WQs, I don't think it should be disassociated. Maybe I'm > missing something btw. I'm not sure overloading DISASSOCIATED with isolated handling is a good idea. The CPU is still online and there are actual per-cpu work items to execute there. Maybe you can split only preferred ones into their own pools and mark them DISASSOCIATED but that sounds rather nasty to me. Thanks. -- tejun