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 1A6CAC5B552 for ; Tue, 10 Jun 2025 12:20:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A7D7D6B0098; Tue, 10 Jun 2025 08:20:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A55196B009B; Tue, 10 Jun 2025 08:20:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 96A466B009C; Tue, 10 Jun 2025 08:20:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 7A1F26B0098 for ; Tue, 10 Jun 2025 08:20:31 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 306CA1CB7B9 for ; Tue, 10 Jun 2025 12:20:31 +0000 (UTC) X-FDA: 83539399062.19.69262E4 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 0679D100008 for ; Tue, 10 Jun 2025 12:20:28 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=AO1T2URB; 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=1749558029; 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=mMeA1vnnlvCC2BQWETMgH4IdWWhMpmY5D4WQM/9Lup4=; b=gtniOe0Mg7elGG0/VATdGiof3sjtD/U0h43rOUImomEKU6Ui0ZesDanMuwbaMw2He4jtLO Do5gixc3WLnN5dRDYFI4RGX+EOFmaV2CZ+nUmOPjsCB7ubXoQAymP0TSsOJvJtTnkNnG90 j8kpt/X7Y0A1JCqIVsk5ERtIgM3q9l8= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=AO1T2URB; 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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749558029; a=rsa-sha256; cv=none; b=hZoNBfQU7ljyB+ijZMczOlaGc8ttrzZUd1NwdMfTbJNa9FkYf2VgqBu1Qre8p6rFN3Dkx5 uE2p5/FqCdxduVa4H14QURK/DryA+ebPJhcTyZrJZUsiiQXPkh7Zp9wNcpjPOGfPN8TcXa f3F9ZI7zpY6ad8P8jy31P14WoF/njNQ= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1749558028; 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=mMeA1vnnlvCC2BQWETMgH4IdWWhMpmY5D4WQM/9Lup4=; b=AO1T2URBa7ao19/6sCVBCemzWQLrHbGm1uBomLi62ngxA4VN9p8p4SexksVGevY297/x6z hJuoWK7GErOpR13fcAlasjvVWsvgWbO7o1NBh+hKysU2t0M2u7HIC4HC4TTQPaC6wKuom7 Bx8oAWPL+Vq1JSMUJEuNK/gVV45OeCk= Received: from mx-prod-mc-06.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-67-tbOnSrmQMlKk49LSq1BdZA-1; Tue, 10 Jun 2025 08:20:27 -0400 X-MC-Unique: tbOnSrmQMlKk49LSq1BdZA-1 X-Mimecast-MFC-AGG-ID: tbOnSrmQMlKk49LSq1BdZA_1749558026 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (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-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id F1A8E1800291; Tue, 10 Jun 2025 12:20:25 +0000 (UTC) Received: from bfoster (unknown [10.22.80.100]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 3306D30001B1; Tue, 10 Jun 2025 12:20:25 +0000 (UTC) Date: Tue, 10 Jun 2025 08:24:00 -0400 From: Brian Foster To: "Darrick J. Wong" 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: 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: <20250609161219.GE6156@frogsfrogsfrogs> X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 0679D100008 X-Stat-Signature: 5zmfpasrrgckbs1z44zdxa6yng7mnzan X-Rspam-User: X-HE-Tag: 1749558028-909821 X-HE-Meta: U2FsdGVkX1/ZFSF1jFGyff0pn8iyPgeAuxQcfBuTDrQ3EOgkLqeIeuHrjcHpLmoad0kf1TdtZ6Tlc1o9c7d3i8wkuVyOIOJAXcX1BD/SDc0sOoxgns6/Gqoj29PWIZ0xSU/6h7aQMztRMYgYwzz/1PLkY9JRudJ2z+N+ZoIEUqERtb1f+P4jF8qZH6JD5Uesvd8Mke9INxDtyn99JNbQrbisqVM/3/iMI8z4pdJKkcFviwYTehdnGc8aA2r4IvVF5wUtVKMa1G5360ZOLTQB+McXKbn+R4ZIH3+I7OwUexNUu4rXJmJl7pvICQtI0Y3KT980gnJOeO4290e5hfKCcq2SyxYqMUMxCiGWtJoIVEvtFigCMlPTkdZF9+xpLFDUze9Wf9zGHeT1dMe7XJbC/xWqb9x5fNhL6gRekvAQQYFE1NsfIhLoEb5RKWyb5d92wFLjRKcK6yBhkM6xQIvTz4f8ulUHprsO7Xtnl86PgL9Jn32qRyrtgpgo0xus5JTg7ikwwqG3cvS/whJq4KRbsc/JTyuK2VfAm2WTg7iCMkjO5e9hmtxQtV49ZzOcGmqsR1fqthc1UR8yOBmMCio46aeldaEn38xatI3Yrb3ClzQIdurxLfmcRk25LkIVOjvJDGUGm0DPEHYzRXX+Qi+areRHQWnVFsnELf1k8RVpzXsAyyFunp9ZzjusveeAvMjFsTjn9JK3SGNqKR4f+vInojVGFy1le4lKCj4L9gXW/FH1mqT5N7IkB+bbptzg5fsNL7C5Hnjv9fb/2I20rdCM2hWILyaTWU7D6WGN5PiNMYJLpoAaeWgOezrXe0bTKP0AcWyYeJR8CNbDCoCLLIdZ9D5pge8Kp6pB2aNQ+DwhJKIqPBl5cp128gZH4TmrkUo3Tln3i83kUkCzm8U+iZGdOxNOHTYfsDT2kUtmMAmV+M0EAj4VvombooJOxnkASf0mfv3vFllLYLZUghDnkGR CixMhReg a3C2ViVnsLX6YJug/SviBUpRTF3lpLcaUESeMnK/Y7UCkU60+EWbH5wDwXQ6yl0UNCEVB9DHlYsQ8I2YNQ0YT5NLZjEMueHhRKXh6ijgh/SMhEA+aCPaxF/b/AFZKvyorUmaKmtLTzDk9cHjutCFrMUlnUvxLAwHCjrT1IUrcUoFWhPkclkV8nSBJ/fP9LDtPtopzSR8WSJM0VaBF5mSc7BlqSV1gOPYA7D/F8l4qZTCJ/9WdjIBflgo0DdFAU8SPLJYs5KSnDCGzpl85vUUHTnK65yHyJwEOXPu/BXI9mVkXFkx3rhAnqLFvccuUgyPI2EMgSiFweuSPG+UImhmo1GqM4nGZnH1kLLFgQV48CzsZ5xuHjOwieJrJsY3fAjp34XN5 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, 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. 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 > > > > >