From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 02A63C8303C for ; Wed, 2 Jul 2025 18:50:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 98E3B6B00AE; Wed, 2 Jul 2025 14:50:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 93F706B00B0; Wed, 2 Jul 2025 14:50:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 856566B00B1; Wed, 2 Jul 2025 14:50:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 73EA06B00AE for ; Wed, 2 Jul 2025 14:50:13 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 0A6B51602BF for ; Wed, 2 Jul 2025 18:50:13 +0000 (UTC) X-FDA: 83620214706.10.6CB35DD Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf18.hostedemail.com (Postfix) with ESMTP id 6B0F91C0005 for ; Wed, 2 Jul 2025 18:50:11 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=cE5VIa3u; spf=pass (imf18.hostedemail.com: domain of djwong@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=djwong@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751482211; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=j/ekbDBR/dOnMHfrCyQmigePFewEu0C/DQE0hu/nNDw=; b=WAnzNzCiWFtCPbvWio0CDv5NTuL41Tkxf2xyCPIdzH0GJSa2UwBJvTh/+MLRCSx2aY+4aO FtQuHRxEv1pU8WmuPN7uy8gMsZXvtkZjTC4zw+EFsgHNhJX5gJLyQ5AUFDtlpnK8nypsET BYisSULwSkmwxqKdrODxHOuXaWdizSI= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=cE5VIa3u; spf=pass (imf18.hostedemail.com: domain of djwong@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=djwong@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751482211; a=rsa-sha256; cv=none; b=2MrzH8NH/Wz608MLpgCqu3gZmGb3ntLpcmktEtQVN4vBEHLtrE+RnRIm12W97uCFNlCfLL OJCBB7mOm6xGwVI6/wQP8DL7oKjRhzhPvYyjB6o5buvsHWcZznSgw9UhhdAwjOtd0jlP3B a1NIscAbJfCxdHklqIpY+SdGuWCyaqc= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id B1F7DA53266; Wed, 2 Jul 2025 18:50:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 53B26C4CEE7; Wed, 2 Jul 2025 18:50:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751482210; bh=o38s9KW5xlL09If/ehLVMBXYY/kbSCjY6FI7qi81S48=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=cE5VIa3unfTIuwN5c3hc8ufJzNz+rbskyspGSVMI2zP6gbIGVCVmNm/GOqiPYXa27 WiJfiud82LYFAWQWUuyBUGQ+QT1TqkaGxTQpDVItcObfvBMJNH2ieuEruNRCjx11Ed AjD/MAq1V+ldytYVXFBQfqtjLW+W+xpTfthwXOZIbT0j3QdJQ6OP1n6VJM6YML0hE7 oHS7p7ieTpUYEXz08wenTG0m5jWcIk+QzH/5ZhT0UUiGIJvqus6Vd3IShw9ONOlqWn K3MWlAMSivYZsQ79tHUp/K20LAcZIISfZnfEvP2coY+hhVT2G3l6nyv4lWoEeFEI/Y ekhdhgFAjsysg== Date: Wed, 2 Jul 2025 11:50:09 -0700 From: "Darrick J. Wong" To: Brian Foster Cc: linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 5/7] xfs: fill dirty folios on zero range of unwritten mappings Message-ID: <20250702185009.GX10009@frogsfrogsfrogs> References: <20250605173357.579720-1-bfoster@redhat.com> <20250605173357.579720-6-bfoster@redhat.com> <20250609161219.GE6156@frogsfrogsfrogs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 6B0F91C0005 X-Stat-Signature: 9j4a37zmk6fkejikfw9nf4ecx1xb4s95 X-Rspam-User: X-HE-Tag: 1751482211-674394 X-HE-Meta: U2FsdGVkX18Uj1Nd7vAKBhulwwSaIm8mrkuEo5F/+8FisjBMiY0pq3BCQp9kFKneo0oHN7SZ0L3yGCDuQB1hCVVUitSO/FTUoq9FHZuWttUyGn7d75z6usnfWzd9sfQmBfiSeZQ6JQhpWh7MRAvAXd8rbWPzLQXShZga0bTaMIU4akFARrkUnTEx4JpOVwxkLQzJ9ySSIpFBcrIlPgTHX2fX0PG5tzZFdJsj39EImXbgZC/japRYiD5+GrFGxMqpO9HaZ2a2zTWCQ4vg9kj6X5ObsSecYveqxRK5IHdYz5JBXtIWYGdw9oRzVTSrEYpo4UitR5VdOSLWAwRnSgiftOGcPLnDd44VIuS3+MyJNx6Oj9Sy9vnkgajCsanKb7/HvMMfx6g93+hlKereCmiCfJHIa/YH59sqpRMCJTHTjpuWnat1v/jYdivuPrmLuXVi6Ptcc1fUgjSzRyr425Svz4fxjTgo16Bem++w7ugFfwdqVwD0t+lp5sdW8/D5tKfzGEE/qftj1LkD2WsB+qR+eDNVjUFVkgyU5MDusstNezj5rIncLQkkMowqvkjWxirk2jIGGpHWJNt6TU4iU+wGK1Vd4bBaLwXRzCzwPmnqf0F/qvp15nJ+N/DMs3F0U1a+Ct4LabryIuQdLE0S3q2AZwjlXSKA5lqRsBFSeZWWBh9NweTJ6ttvZehJqyVMpHrWLfnE4HOlJycahKxMOA29YVop085LWI2WGc4Sz5qZ+wiRx0aipIiNTTGLvUWl2ZpUxwZTH5kwITGhIaQQGXUNIUSDFXystyq3BdnCwI0K3p2fIykxuavLOf4+d/GptySH7NvvTpikfhb8XwJGSR3LF4TyGj6iUM0F4g0MtAt8bNjBo1HEznhx3v4nU5Jdzdz1CKnGKWzp2ZDmZwnVBF4d0qv7y9EXj0+j0boEk42mvTlDYkEJwHg168hvPnaE3HwAIhjzwZGbpKgE9CLMHhO i/Cz/z/N p4UTLHeutuTCfSwQPCyNP0vUtqUY+9SkTZ2WUUdTDndIzBI3W8KlqjIbDq5jgZ5DJU9E8LawqvITtAM+izbxKMGt7/mTSI2E0dKi7L9HmWFIoqZd62xrZ+/iU1DQxzvES0eXq+kK4OsMD2EXM9Ri7s2wmknAr1H8N3TCIjpOaOeTFes1bCNKfiirUp0KXLENSKNm4jd3pL/gwlfcwI05rMcjDw7PRVb7EwPR1FJuE3LK6zB+6/cwsdn58yB/KnHU6Nu0otH+0Xr5TJAFFmEo0pvCN5g== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Jun 10, 2025 at 08:24:00AM -0400, Brian Foster wrote: > On Mon, Jun 09, 2025 at 09:12:19AM -0700, Darrick J. Wong wrote: > > On Thu, Jun 05, 2025 at 01:33:55PM -0400, Brian Foster wrote: > > > Use the iomap folio batch mechanism to select folios to zero on zero > > > range of unwritten mappings. Trim the resulting mapping if the batch > > > is filled (unlikely for current use cases) to distinguish between a > > > range to skip and one that requires another iteration due to a full > > > batch. > > > > > > Signed-off-by: Brian Foster > > > --- > > > fs/xfs/xfs_iomap.c | 23 +++++++++++++++++++++++ > > > 1 file changed, 23 insertions(+) > > > > > > diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c > > > index b5cf5bc6308d..63054f7ead0e 100644 > > > --- a/fs/xfs/xfs_iomap.c > > > +++ b/fs/xfs/xfs_iomap.c > ... > > > @@ -1769,6 +1772,26 @@ xfs_buffered_write_iomap_begin( > > > if (offset_fsb < eof_fsb && end_fsb > eof_fsb) > > > end_fsb = eof_fsb; > > > > > > + /* > > > + * Look up dirty folios for unwritten mappings within EOF. > > > + * Providing this bypasses the flush iomap uses to trigger > > > + * extent conversion when unwritten mappings have dirty > > > + * pagecache in need of zeroing. > > > + * > > > + * Trim the mapping to the end pos of the lookup, which in turn > > > + * was trimmed to the end of the batch if it became full before > > > + * the end of the mapping. > > > + */ > > > + if (imap.br_state == XFS_EXT_UNWRITTEN && > > > + offset_fsb < eof_fsb) { > > > + loff_t len = min(count, > > > + XFS_FSB_TO_B(mp, imap.br_blockcount)); > > > + > > > + end = iomap_fill_dirty_folios(iter, offset, len); > > > > ...though I wonder, does this need to happen in > > xfs_buffered_write_iomap_begin? Is it required to hold the ILOCK while > > we go look for folios in the mapping? Or could this become a part of > > iomap_write_begin? > > > > Technically it does not need to be inside ->iomap_begin(). The "dirty > check" just needs to be before the fs drops its own locks associated > with the mapping lookup to maintain functional correctness, and that > includes doing it before the callout in the first place (i.e. this is > how the filemap_range_needs_writeback() logic works). I have various > older prototype versions of that work that tried to do things a bit more > generically in that way, but ultimately they seemed less elegant for the > purpose of zero range. > > WRT zero range, the main reason this is in the callback is that it's > only required to search for dirty folios when the underlying mapping is > unwritten, and we don't know that until the filesystem provides the > mapping (and doing at after the fs drops locks is racy). > That said, if we eventually use this for something like buffered writes, > that is not so much of an issue and we probably want to instead > lookup/allocate/lock each successive folio up front. That could likely > occur at the iomap level (lock ordering issues and whatnot > notwithstanding). > > The one caveat with zero range is that it's only really used for small > ranges in practice, so it may not really be that big of a deal if the > folio lookup occurred unconditionally. I think the justification for > that is tied to broader using of batching in iomap, however, so I don't > really want to force the issue unless it proves worthwhile. IOW what I'm > trying to say is that if we do end up with a few more ops using this > mechanism, it wouldn't surprise me if we just decided to deduplicate to > the lowest common denominator implementation at that point (and do the > lookups in iomap iter or something). We're just not there yet IMO. I suppose it could be useful for performance reasons to try to grab as many folios as we can while we still hold the ILOCK, though we'd have to be careful about lock inversions. --D > > Brian > > > --D > > > > > + end_fsb = min_t(xfs_fileoff_t, end_fsb, > > > + XFS_B_TO_FSB(mp, end)); > > > + } > > > + > > > xfs_trim_extent(&imap, offset_fsb, end_fsb - offset_fsb); > > > } > > > > > > -- > > > 2.49.0 > > > > > > > > > >