From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) (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 94B792E11D2; Fri, 6 Feb 2026 06:25:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.95.11.211 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770359131; cv=none; b=IQvzBqCPvwpbsN7vgHkRc2zNQAceLkRxTTx2XT0nxXoKQEOaMpObNUHM4H/7sdhTw3Qo0mVT+oSRB7AerJQ4SYG9PkqzoQzyEpeA0hD8hub0wfJh6osADsDKLLZhaeirccdy1QwIMSgimFuPKy0tOrPuMdZFZ7du0h9ioazhmNI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770359131; c=relaxed/simple; bh=ogYQLZ7iWfEGF07dtSs2T9QN0dSN90jwWkW/AjJXN3M=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kdIfJIPembane2oBI7at7btGGjEUyE0uGNMEPNM+0K3pnKoZhibpKiDhvTCIVXW738oNVy+jUcjHJPaITODJcgQXZANluv7dcfIh+ZsJhyCodb8CasDxH4erJ5VfXHAbq7UWzuwrlvzAJ6l34KmPKYYIIQuwVgLEbdRKIEKIV6w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lst.de; spf=pass smtp.mailfrom=lst.de; arc=none smtp.client-ip=213.95.11.211 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lst.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lst.de Received: by verein.lst.de (Postfix, from userid 2407) id 8033468D0F; Fri, 6 Feb 2026 07:25:27 +0100 (CET) Date: Fri, 6 Feb 2026 07:25:27 +0100 From: Christoph Hellwig To: Kundan Kumar Cc: Brian Foster , viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz, willy@infradead.org, mcgrof@kernel.org, clm@meta.com, david@fromorbit.com, amir73il@gmail.com, axboe@kernel.dk, hch@lst.de, ritesh.list@gmail.com, djwong@kernel.org, dave@stgolabs.net, cem@kernel.org, wangyufei@vivo.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-xfs@vger.kernel.org, gost.dev@samsung.com, anuj20.g@samsung.com, vishak.g@samsung.com, joshi.k@samsung.com Subject: Re: [PATCH v3 0/6] AG aware parallel writeback for XFS Message-ID: <20260206062527.GA25841@lst.de> References: <20260116100818.7576-1-kundan.kumar@samsung.com> Precedence: bulk X-Mailing-List: linux-fsdevel@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: User-Agent: Mutt/1.5.17 (2007-11-01) On Wed, Jan 28, 2026 at 11:58:25PM +0530, Kundan Kumar wrote: > This series is intended to replace the earlier BDI-level approach for > XFS, not to go alongside it. While BDI-level sharding is the more > natural generic mechanism, we saw XFS regressions on some setups when > inodes were affined to wb threads due to completion-side AG contention. > > The goal here is to make concurrency an XFS policy decision by routing > writeback using AG-aware folio tags, so we avoid inode-affinity > hotspots and handle cases where a single inode spans multiple AGs on > aged or fragmented filesystems. > > If this approach does not hold up across workloads and devices, we can > fall back to the generic BDI sharding model. I fear we're deep down a rabbit hole solving the wrong problem here. Traditionally block allocation, in XFS and in general, was about finding the "best" location to avoid seeks. With SSDs the seeks themselves are kinda pointless, although large sequential write streams are still very useful of course, as is avoiding both freespace and bmap fragmentation. On the other hand avoiding contention from multiple writers is a good thing. (this is discounting the HDD case, where the industry is very rapidly moving to zoned device, for which zoned XFS has a totally different allocator) With multi-threaded writeback this become important for writeback, but even before this would be useful for direct and uncached I/O. So I think the first thing I'd look into it to tune the allocator to avoid that contention, by by spreading different allocation streams from different core to different AGs, and relax the very sophisticated and detailed placement done by the XFS allocator.