From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="SsqqBrXS" Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A95AA83; Wed, 22 Nov 2023 23:09:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=gfCnOTMWBGaQ9EtuvEblhtZqjLaDKJa4eek8GzzpNew=; b=SsqqBrXS2BCELuoQIKvB+FR60B UYdqZwGstD3l8GEeErtSiNDBLcKi7uYc5VgDm6GYMhrm8GbBdGQbjHofRwLPn1PXGYqxFrI/pPiyQ 29W+DFSray+cnn88j4IMTsVyz/FSdre2xoN8QN9qW5kr104euAhcfN0RTIi2kBEDsit44HWDdvKUO YAL6NJxfeayl69nbxN/fYc+y7YyFAk5udjjGz4J+881IeUI6YZfCKZkOL6dKHgbC6VHDg8MW+fUEv rNV0/olJ4yaSOwnWnGK5Frlx4OC0od4n4xZtDZ9+tlwjJnPjmfRfdwkB2MFIe3569dfr8crEpdaWF gSvtUMYQ==; Received: from hch by bombadil.infradead.org with local (Exim 4.96 #2 (Red Hat Linux)) id 1r63pt-003zAg-1p; Thu, 23 Nov 2023 07:09:17 +0000 Date: Wed, 22 Nov 2023 23:09:17 -0800 From: Christoph Hellwig To: "Darrick J. Wong" Cc: Dave Chinner , Christoph Hellwig , Jan Kara , "Ritesh Harjani (IBM)" , linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [RFC 2/3] ext2: Convert ext2 regular file buffered I/O to use iomap Message-ID: References: <20231122122946.wg3jqvem6fkg3tgw@quack3> <20231123040944.GB36168@frogsfrogsfrogs> 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: <20231123040944.GB36168@frogsfrogsfrogs> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html On Wed, Nov 22, 2023 at 08:09:44PM -0800, Darrick J. Wong wrote: > The particular idea I had is to add a u64 counter to address_space that > we can bump in the same places where we bump xfs_inode_fork::if_seq > right now.. ->iomap_begin would sample this address_space::i_mappingseq > counter (with locks held), and now buffered writes and writeback can > check iomap::mappingseq == address_space::i_mappingseq to decide if it's > time to revalidate. So I think moving this to the VFS is probably a good idea, and I actually argued for that when the sequence checking was first proposed. We just have to be careful to be able to map things like the two separate data and cow seq counts in XFS (or anything else complicated in other file systems) to it. > Anyway, I'll have time to go play with that (and further purging of > function pointers) Do we have anything where the function pointer overhead is actually hurting us right now? One thing I'd like to move to is to merge the iomap_begin and iomap_end callbacks into one similar to willy's series from 2020. The big benefit of that would be that (together with switching write_cache_pages to an iterator model) that we could actually use this single iterator callback also for writeback instead of ->map_blocks, which doesn't really work with the current begin/end based iomap_iter as the folios actually written through write_cache_pages might not be contiguous. Using the same mapping callback would not only save some code duplication, but should also allow us to nicely implement Dave's old idea to not dirty pages for O_SYNC writes, but directly write them out. I did start prototyping that in the last days, and iomap_begin vs map_blocks is currently the biggest stumbling block.