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 BEE0A2C0F96 for ; Tue, 2 Dec 2025 17:37:59 +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=1764697079; cv=none; b=sPXzy3P5smtuygrAR1OJnDQ6KnLEmTnQ3LxoX+T5LcfKm3as6lHMlTw534Eu+V9UrfLHue/dCXtHeHybK9lkc64Rq3Pd5u4ByIIhOkQr8zGv0/hvyoSlRSC1tEk1Q6OkR8OFVu3ODigCK8A/6E+jLhLvhngKB3vUYlSqt06fRAQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764697079; c=relaxed/simple; bh=FrGWoVHEQiIssfFKH4js89H2wnP6Xe4XO+FCkr6Q3tc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cndBkmtx4W0+oU/K6tOeQPvc3zwB4Co7BRQrrtssUGpSSdU6Y61jyxCzVF9M3UopLszqXNu02ooJbusgUKuL4tnuF5mMTztgTDXGEEQd6638u0kXlTKete8CtojtWfYSEGk8BQ6SQzd8gCxFCdB2JtX+Qal5QQUAifnhucVxc/s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FHSoQSwD; 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="FHSoQSwD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 386A5C116B1; Tue, 2 Dec 2025 17:37:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764697079; bh=FrGWoVHEQiIssfFKH4js89H2wnP6Xe4XO+FCkr6Q3tc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FHSoQSwDJpntXP89c1Y4HTWSzpP8qqXMlBrDJTh9H/ZX8MOhAYgN/Kt6CjxtNmh60 jD9ByA0PjAycPhKbGwZXHrwkrG25e6SBIX5FiLsZhWxR96Xtjk02fNvUEz5tXGBC8r HI1awt1TIqC6o5+1gOhg0DC/kCuvc+qN6zdjybrvAfcfvp1w2FycMQXHP0OPA5aHFo N1K4GOILgMKOeQ0sih17XzJ+G+IpyviNyWQAj7xpOokwNYf5WNMIpjYh8r/FzjbPvM EQRGUcckfDaeHUwYiew+2ROKpTpAjXnSunPntrKTlCGMQH5HjyV8iVkWywIaLO5sSL ULLp6o1Gb8TrQ== Date: Tue, 2 Dec 2025 07:37:58 -1000 From: Tejun Heo To: Lai Jiangshan Cc: linux-kernel@vger.kernel.org, Lai Jiangshan Subject: Re: [PATCH 1/2] workqueue: Use pwq->work_color for wq_barrier Message-ID: References: <20251125103126.684929-1-jiangshanlai@gmail.com> <20251125103126.684929-2-jiangshanlai@gmail.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: <20251125103126.684929-2-jiangshanlai@gmail.com> Hello, On Tue, Nov 25, 2025 at 06:31:24PM +0800, Lai Jiangshan wrote: > From: Lai Jiangshan > > wq_barrier work items are internal and do not count as user work items. > They do not participate in flush_workqueue() except for a sanity check, > since wq_barrier owns the PWQ reference. Therefore, any work color is > acceptable; just use the latest pwq->work_color. Maybe it is but I really don't like it. It becomes a lot harder to think about and that makes things more fragile in the long term. I think it should either not participate at all or do something straightforward like inheriting the color of the work item it's flushing. Even just thinking about the original problem that added flush color to barrier work items becomes trickier. We can no longer just think that "oh yeah, no new work items and all barriers match the target work items, so flushing should wait for the whole thing". It now becomes "what happens if a new flush_work() is queued after the latest flush_workqueue()? does that still wait for that new barrier item?". In fact, I'm not sure it does. So, please don't do this. Let's keep things conceptually straightforward as much as possible even if that costs a bit more code. Code is often a lot cheaper than cognitive overhead. Thanks. -- tejun