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 70D9CC83F21 for ; Tue, 15 Jul 2025 12:32:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 074FB6B00BB; Tue, 15 Jul 2025 08:32:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 04CD76B00BD; Tue, 15 Jul 2025 08:32:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ECBE26B00BE; Tue, 15 Jul 2025 08:32:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id DBB6D6B00BB for ; Tue, 15 Jul 2025 08:32:18 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 975F158FB9 for ; Tue, 15 Jul 2025 12:32:18 +0000 (UTC) X-FDA: 83666436756.01.7214DA7 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf14.hostedemail.com (Postfix) with ESMTP id C6296100012 for ; Tue, 15 Jul 2025 12:32:16 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=SaJBF3sA; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf14.hostedemail.com: domain of bfoster@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bfoster@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752582736; 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=PMWLDsaxYk3mtycE5KTlBYX1K5MmGbSOcv51c5mvkh8=; b=BPzaUZT1ENZZbxz73/xZKUj6HkHf2gUOaa+D43j8kzaRxv6MiVPkpD5xoIgYAMihbZcLlD uz2GeUUpcnXIq5qhwdZqjXsSC3DK5Dxh46n+UBr37daNlgJrV20soKUFs8tTgoq8SaoLKQ KCYSJ0zrseKEmMBJS8L/QzKRQeDb6eI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752582736; a=rsa-sha256; cv=none; b=HkjiX6SlTSrzr63V/NP5BLFFbbNPGEqazOz3dalK22ldQTX10wqsWH91kwKWKsQ7+sZwCf U1XJob8DAn6lM8QgYzbFO4b3qXzHxNZNaDZwKfBjCYPxMoHVdECz33JqryIgLueYVYD9n8 ku6eTaZUhgnaaxxsDqS+U8nP7TlppFM= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=SaJBF3sA; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf14.hostedemail.com: domain of bfoster@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bfoster@redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1752582736; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=PMWLDsaxYk3mtycE5KTlBYX1K5MmGbSOcv51c5mvkh8=; b=SaJBF3sAnAomWrPlLZunnaz1AKMkON2EjGPCkXboJxYMuucURdBnV9rMY+8P4SzgmIs4yr 9C0HfmPVepTmE5kvsw/BZzkBFjowDLcT/wncR4/h4rpjmmZJNZSuJZShEfGmfbGCg8f8Pq 1lPx1DyF3H9KZv97agEyFBuZ9sVa8s8= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-161-TC3fsio2O-iujKV3UFtL8w-1; Tue, 15 Jul 2025 08:32:12 -0400 X-MC-Unique: TC3fsio2O-iujKV3UFtL8w-1 X-Mimecast-MFC-AGG-ID: TC3fsio2O-iujKV3UFtL8w_1752582731 Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 507B018001E2; Tue, 15 Jul 2025 12:32:11 +0000 (UTC) Received: from bfoster (unknown [10.22.64.43]) by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id D1655195609D; Tue, 15 Jul 2025 12:32:09 +0000 (UTC) Date: Tue, 15 Jul 2025 08:35:51 -0400 From: Brian Foster To: "Darrick J. Wong" Cc: linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org, hch@infradead.org, willy@infradead.org Subject: Re: [PATCH v3 5/7] xfs: fill dirty folios on zero range of unwritten mappings Message-ID: References: <20250714204122.349582-1-bfoster@redhat.com> <20250714204122.349582-6-bfoster@redhat.com> <20250715052811.GQ2672049@frogsfrogsfrogs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250715052811.GQ2672049@frogsfrogsfrogs> X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15 X-Stat-Signature: 484ou3drkjow9je53q5fhf9drzqwz7cx X-Rspamd-Queue-Id: C6296100012 X-Rspamd-Server: rspam10 X-Rspam-User: X-HE-Tag: 1752582736-648921 X-HE-Meta: U2FsdGVkX1/rRgkahxos2vTSad3tXxlhEVkDo0pOMiEZjFUp0G7LQQD5M6RIV6bphQAZRe82nzv38ntv/kVJTw8+xPk6WeJ5SfqwahUs5Jrkz6gDqR86LRNYTChNCqtV+LRfq0sEQo86R+X+VZAZKwaqOd41/oaPykTTMEEMeZwZrXm9AfExpJ2bfZgoAHKkt1DBIlYRAEaR6TPoONXKkYourhXOqZfEwD/rKomhH9S+e6d80uSI5JwRo7xPxGs5su2AWW/1hP0sSiGD1J1nZcNL+VaHQBjt+awpLIs4ka4rm+k/5yzv/2NUrG6T18OECMssij/qhvMtasztDc+8aBmtz1UBDop63YoWX6voPeINepAeFPgolUGD+r23S10BAuyMnmt1IXepe6pUBowHKbIPwAW/pIIjDKQDJdSFa6w+4Xwv/k8Vjmh1FfbSePPUGM3gH9dtm/3wj12RM4rRB2nYRUcbTJzvrBpagGS3Ouf/OWEhlsMGWEgfnbhQ4PWetxWbY2FonIsofI7DpQbyLL1to8zQ6hAJ5zUgQQ80RpKpaYlL3w9880uU5R9VJNpYrBIRk2hbT3FjJj8J3a9fAqx2ZZs9/CGOsI8eLFGll/4E0/jQkJKwB/+D2/ZMbkwl5dwvzTk7gAofvvG2IlHKKlocFBUEsz2r9JidUJ7gyLYJGidALe9QOGIBhPozGs3A72MV4YE5CZ/z50S5la+4dD6hjyDdYien5fVvo7L0cH6zzt/uL+dvFIJ3eM/dqSn83r5UjjSPhs4IsNmZIkssyNx9LgnB97247XDr1FlCx+LUeuzB+zq9So5ciUxpIWWjnzYeiM4O5adAcd2nyAy0pJIMQgYchdDdd7B2aungEPNj008npn0tNGtq0/jIz7wO9UosQnEzSS6g5zit85NE/GrcmyakkCt5XsWMyHDMLR+Y8Mvu9JOQD4XaODtsBZVv+jhvCfficvPljD0GC3c U5akDWeG tBOwBIt8aRj3MdDtnBPFIcHp8Xt44lv27LewncaoEWjUJh2ulFa7ME6kbcvSQVAyfpZEBg3RWlqgyR+BBFBiG2ONFIMUFoIT/dO8qUbFkr680W/5OiKayTU/PS3+WmGpW8cPR3cgqZ44pXSRHkZUcruvTby95lcb/S8kkg/fUJKOiRG1HfTF9BlSUHYxHLFGHbMDELpay9nvC+2rSfBFpyT0+ZLRn6deItQrJUZf+8SvEHWEKrlQOaC+CEvZmnlUK439mKLCSu21BXoFAXQLUI7ZiBgyNvmGmCPC5fext2mD5BEh7wWgEhINp5zxqGYqWQD//n4t1apS1YGdRx0O/zdlu/6gWFDiiWd0renkbWe2EZLvXetyWdoCvoZhcJM6asGVWGWzP6Ndt6qAqK9U0RTmutA== 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 Mon, Jul 14, 2025 at 10:28:11PM -0700, Darrick J. Wong wrote: > On Mon, Jul 14, 2025 at 04:41:20PM -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 > > Reviewed-by: Christoph Hellwig > > --- > > 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 > > @@ -1691,6 +1691,8 @@ xfs_buffered_write_iomap_begin( > > struct iomap *iomap, > > struct iomap *srcmap) > > { > > + struct iomap_iter *iter = container_of(iomap, struct iomap_iter, > > + iomap); > > struct xfs_inode *ip = XFS_I(inode); > > struct xfs_mount *mp = ip->i_mount; > > xfs_fileoff_t offset_fsb = XFS_B_TO_FSBT(mp, offset); > > @@ -1762,6 +1764,7 @@ xfs_buffered_write_iomap_begin( > > */ > > if (flags & IOMAP_ZERO) { > > xfs_fileoff_t eof_fsb = XFS_B_TO_FSB(mp, XFS_ISIZE(ip)); > > + u64 end; > > > > if (isnullstartblock(imap.br_startblock) && > > offset_fsb >= eof_fsb) > > @@ -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); > > + end_fsb = min_t(xfs_fileoff_t, end_fsb, > > + XFS_B_TO_FSB(mp, end)); > > Hrmm. XFS_B_TO_FSB and not _FSBT? Can the rounding up behavior result > in a missed byte range? I think the answer is no because @end should be > aligned to a folio boundary, and folios can't be smaller than an > fsblock. > Hmm.. not that I'm aware of..? Please elaborate if there's a case you're suspicious of because I could have certainly got my wires crossed. My thinking is that end_fsb reflects the first fsb beyond the target range. I.e., it's calculated and used as such in xfs_iomap_end_fsb() and the various xfs_trim_extent() calls throughout the rest of the function. Brian > If the answer to the second question is indeed "no" then I think this is > ok and > Reviewed-by: "Darrick J. Wong" > > --D > > > > + } > > + > > xfs_trim_extent(&imap, offset_fsb, end_fsb - offset_fsb); > > } > > > > -- > > 2.50.0 > > > > >