From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 32DE6338932 for ; Thu, 19 Feb 2026 09:20:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771492859; cv=none; b=lFy8BoYRy9XEAotd8oOgYm3lY8GQvmcVntfa5TjVb93rpheKNvItijySAYilSXLZH9nmj0YB4wUtRVVOUg0gZMX0JcipHz65K2T60KnqqteNF5XvAUs0Bm92v3U7LjRC9NPxXVwk7XDRRl/SDENtu49qYNzxbvsZSN6iOIUMYfI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771492859; c=relaxed/simple; bh=xKXts/skz0JyIelk8FhsIJVjS5AJwJaHz2pl7SfkktE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Ufwn/p3hQKIuIn0UB/9PlEf5ECqeOWehJv8HlX7uTiTocNxKF+6fo/0CsIIdx2sNgoYsNTggiRhBH9vp2OArHpRP8G3QUo98nxucFQgIBWQOcWlMDJgcYSwW1aZu4cKEhrEzAhO80bKF/3dAsKPt1mkwndjyYyHNU/N/nHmgd44= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=HhSlNfq1; arc=none smtp.client-ip=209.85.221.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="HhSlNfq1" Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-436e87589e8so719859f8f.3 for ; Thu, 19 Feb 2026 01:20:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1771492856; x=1772097656; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=+FlmjqWniPC3jVFM4ecKSA8vcZ4REL4AR5R1sKakC6E=; b=HhSlNfq1aK66riOhvJRGmKVmwUE9x101pY3piUYViH0cXEwhc5pbTnZh89v7RoVCQm Ro10cpiJoLdVuA2TyGpc/DdErnJY4Eh5IJap8jQs6bkwlAj4rq4UYjuDQwGRii1NE8Z3 MYVIZwI0OgLdJbP4KhLNIFrU/UEXH4J0q1uahFzC6qTHCrXobXMUY78hLK9V6DquDnM5 zCiJu++S9g5GRkCCq6rCdHTzxkvr6SbklmqxQo8WUbt6dnzNUrK2nh+UYvD5W0OZgO/p 0pdun0Vw9ULnbRav3lMAh38AkvXxHqaKWdNCkyIPl9n6uwY9e+bk7LPV5x5NaqUakA99 25bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771492856; x=1772097656; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+FlmjqWniPC3jVFM4ecKSA8vcZ4REL4AR5R1sKakC6E=; b=pjLlXw+9guPA5mjDjhwkourm19WQy2mIkEWKWTIjDaUwqrB6wmrtRoHDjeOjMcJEHk iYIrwdGhDBUH1quLm2uNpvjNSSOnjJt3U/HWS2LNloU5zckO8pelO00jRhlTuN0e9zvo vcYtAambjiRvX0o6tVLII1a7SAhNKZCj50YR52CO4FS7r3jce1DIIXjg5u0dAnoU1FC/ hkMn+67oH770g1YQ4AbkedGXzjrDXsasAjDgx/W9thIwZdgopTTxSk2wdSl7JuHa5fU3 +kEg9XuX3NfyTOxRFBGX8hrOPnrrfY5N1CkjDNKQVry/9FU7YOLFjArFhkkjFdPYPEdK P66A== X-Forwarded-Encrypted: i=1; AJvYcCXs8w4sxxuV7Z/y7Tvf/hAoIV90D73Y4T/Gngx/OXKdHVguZs56Bj5G4xdldM0LZmqkyj6k2sRuWbQcPZg=@vger.kernel.org X-Gm-Message-State: AOJu0YzuS9rzogYQoSOoVKBacQ3rgXAzUeWZGBQDBh2rUnSX65kRs1yK JHaF3N4XXxTDBiifpjWuTkKe3YuiAlGXcGz6vmP/g19g+MRYYw0VcJ5XkAf1N/dg3ujognP8NVF wtzxc X-Gm-Gg: AZuq6aJtl1Q46Ep3RYNgpBuEkQx/FhivkdzsyG2gitId2MEPGEYDQQkmZzM+VqWGDXJ MhMw8uLowiO7P9z1ay3QSnGoo/SwdOIhLs/IvtL69bVvRn/uwrSjPdYif8Ok9xLs2tTFJ3QWeW0 5R4K3dFJpI5g4QgeZY4bK4t+hNrKqjLfVOW4nv/gUq7K2r24wCQcsF/DuFyhlzNKZu4WrYQx1gs c6omeLyrxiOntfilR1ddAFVzikpH3URRIk8xVtBM8nAf7nNulu8waoTEa6pt1F8B8Trv+pIIxCs K4EOkkYNLnK8zPHzwfI5lTfSougbr5f9+Kf7vqxwZ7Vhwck+V9CveOwxxqvPQG3QpgZAFNVE1nF bKxZ1jBamPCBWELYqCRP1EoHJrewXGVyOYn8O3OJjxP/pA1rDIsmDqSNSgl1Ar9lnzxfH3RNwVi EpgJtRYaawHkOThnPgxW43qvXYJ6cdU8A= X-Received: by 2002:a5d:5917:0:b0:437:99d2:c115 with SMTP id ffacd0b85a97d-43799d2c495mr28106790f8f.26.1771492856402; Thu, 19 Feb 2026 01:20:56 -0800 (PST) Received: from localhost (109-81-84-7.rct.o2.cz. [109.81.84.7]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43796ac8d82sm48035914f8f.31.2026.02.19.01.20.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Feb 2026 01:20:56 -0800 (PST) Date: Thu, 19 Feb 2026 10:20:54 +0100 From: Michal Hocko To: Dave Chinner Cc: Marco Crivellari , linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, Tejun Heo , Lai Jiangshan , Frederic Weisbecker , Sebastian Andrzej Siewior , Anthony Iliopoulos , Carlos Maiolino Subject: Re: [PATCH] xfs: convert alloc_workqueue users to WQ_UNBOUND Message-ID: References: <20260218165609.378983-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: On Thu 19-02-26 12:24:38, Dave Chinner wrote: > On Wed, Feb 18, 2026 at 05:56:09PM +0100, Marco Crivellari wrote: > > Recently, as part of a workqueue refactor, WQ_PERCPU has been added to > > alloc_workqueue() users that didn't specify WQ_UNBOUND. > > The change has been introduced by: > > > > 69635d7f4b344 ("fs: WQ_PERCPU added to alloc_workqueue users") > > > > These specific workqueues don't use per-cpu data, so change the behavior > > removing WQ_PERCPU and adding WQ_UNBOUND. > > Your definition for "doesn't need per-cpu workqueues" is sadly > deficient. I believe Marco wanted to say they do not require strict per-cpu guarantee of WQ_PERCPU for correctness. I.e. those workers do not operate on per-cpu data. > > Even if these workqueue are > > marked unbound, the workqueue subsystem maintains cache locality by > > default via affinity scopes. > > > > The changes from per-cpu to unbound will help to improve situations where > > CPU isolation is used, because unbound work can be moved away from > > isolated CPUs. > > If you are running operations through the XFS filesystem on isolated > CPUs, then you absolutely need some of these the per-cpu workqueues > running on those isolated CPUs too. The usecase is that isolated workload needs to perform fs operations at certain stages of the operation. Then it moves over to "do not disturb" mode when it operates in the userspace and shouldn't be disrupted by the kernel. We do observe that those workers trigger at later time and disturb the workload when not appropriate. > Also, these workqueues are typically implemented these ways to meet > performancei targets, concurrency constraints or algorithm > requirements. Changes like this need a bunch of XFS metadata > scalability benchmarks on high end server systems under a variety of > conditions to at least show there aren't any obvious any behavioural > or performance regressions that result from the change. This is a fair ask. We do not want to regress non-isolated workloads by any means and if there is a risk of regression for those, and from your more detailed explanation it seems so, then we might need to search for a different approach. Would be an opt in - i.e. tolerate performance loss by loosing the locality via a kernel cmd line an option? I am cutting your specific feedback on those WQs. Thanks for that! This is a very valuable feedback. Thanks! -- Michal Hocko SUSE Labs