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 CA9B3C61CE8 for ; Mon, 9 Jun 2025 16:12:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 41AE16B0088; Mon, 9 Jun 2025 12:12:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3CB216B0089; Mon, 9 Jun 2025 12:12:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3096E6B0098; Mon, 9 Jun 2025 12:12:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 147236B0088 for ; Mon, 9 Jun 2025 12:12:24 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 7C6551D1899 for ; Mon, 9 Jun 2025 16:12:23 +0000 (UTC) X-FDA: 83536354566.22.5C123A3 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf23.hostedemail.com (Postfix) with ESMTP id C391214000C for ; Mon, 9 Jun 2025 16:12:21 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="Xx6gy/0w"; spf=pass (imf23.hostedemail.com: domain of djwong@kernel.org designates 139.178.84.217 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=1749485541; 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=0VS2ku+Qn9FHkZs7xEa8fo8mIVgRZwb16JGJY02r/20=; b=FOO1fIRVh4G0bbawBdA6q/WRF10qm3WN3zKpZMqARgULNcpvIX2cTuW4m7lwgiv/8HcW9j Xpo6l6LzBD6sE5hVHunwSjWrzmrwcdW/IMLh9FrBbudXEKcYPGadDk+zbUPw77MIwV+Ff9 inkquMnEtOA0jkustihat5zrXqt9RkE= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="Xx6gy/0w"; spf=pass (imf23.hostedemail.com: domain of djwong@kernel.org designates 139.178.84.217 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=1749485541; a=rsa-sha256; cv=none; b=K9ERIIamVEpj4pRAmnMXnrikJGUQiyseg9Z79C59Ho+KAf37mfEYEc25H+ErmrqScnMIde Q35yGdaLpSIS0orDSYe9tsz71/fglqmvAGsh1SQkRL4b061iw1gmuEOQ/4KCNbEjDQMCs+ thlFq6ugx1NnfYcRwG6xRs+KEhoqjEg= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 3F2CC5C4DA9; Mon, 9 Jun 2025 16:10:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 94ACDC4CEEB; Mon, 9 Jun 2025 16:12:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1749485540; bh=TnxPRrt3FuETnxO3K1XsXNg8xwyrps9vUrbwT0pBR58=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Xx6gy/0w0Cox/y0AwwMFXT+Q4DBELLGAjGsCLZEVrqM2JMSqQG2Fgsd5qEWlAATqz CR55SLHsbrNNCvCI668SvNjRlvvWB9c144BStsaP0v+dqUzbV+EAE6iBsOdADtR7dW MfDqiR58aeXrs8PJcqnpxxmMcs1FQrbKQB6jJjaLHKWMf7EM50AJgHCl7D2RoWtXim FA6tm8qs3nlPneczfKl0c1ne/YfrE/MZ2oy9UFKFIGk6z8Xt2O3alEFIJUpmDB+pra 9faR5ddifjqxmMKoIfioKA+SFfqVLsu4aDkzuei9DP19l8saUp1R1IY/1DAYcnOdms vLBmLzs8ELrnA== Date: Mon, 9 Jun 2025 09:12:19 -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: <20250609161219.GE6156@frogsfrogsfrogs> References: <20250605173357.579720-1-bfoster@redhat.com> <20250605173357.579720-6-bfoster@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250605173357.579720-6-bfoster@redhat.com> X-Rspam-User: X-Stat-Signature: 46k6zo9f7wnneq7gmtous5mk7hnfckbf X-Rspamd-Queue-Id: C391214000C X-Rspamd-Server: rspam11 X-HE-Tag: 1749485541-182786 X-HE-Meta: U2FsdGVkX18P7yUtv92o1GTiz+5uoFGCRPsV+KLqx/WpPXXR2DzwgpoqbvEkAyyIOK+dbNBIQv0SSEPcwSdWc7AXjfqtWim6gSfwSW3dpsdVi+/57rHlGqcTRweyjJwD6ZJLpAZ58oM1OUgUWJ/HtmnDGFfCYK/BfiIZ7HuvY0gf//tRClTAMnThEX01VIzLv8aidGWIq58HNBdlLeVJ/f+l7a3cVYXV5yVcL1wgeJCSq6/zxLhPY2XZCiKJeOyY649PnVRoF9zfKAoHoTfurys1sSnzJsRm2xAABTzrOxWbH5Eu4rfd2H+S02V0SSiloiqeG9I+bL1k/UNaJb3GB/FOxWuN7CepnUTilqsfzMbPsK2za8hrCPLZqKFbnwgfLv3XUPEvwHcE7amSH3zpNy492iqUj6RKHRhad+/82LWFaA/a1pzwqyIKrkuX2Ebf8jOe3kWzTvkgNmRrMFER8pTFXp74X2utAwn0IRsHN8kqZFiE7pWTRTk4MJJ95xhxbeF1LVS01C9UMS+0wTMODJA7hqmw7f0n12myDQQis64PmJp5/TNrQanbBSN9nHo6TTLWduEdhEx0vHoyuFUdZyQGEpjbDXwCYY1QQLpPyUlS+anYfeO2U1Ny/x8SsiYi30L8SQfKD1Fmr4H77eedchv0eM0QcFtkyUrZguOI4SCOwzBJAT3u0QIeiaE4TnZ9Y3qE7VU1vJ7Ux2YTkdihJffROb4q1nWKpRq3+xy3nPrRQtzMBZIhCrV4SECDqXd1gO2VjeO+oafkpZqxL8kcZ5Zop+5jdQJ6Km1H6e/iFjHVHrRYPQ+k/wEyFrdMo+WlHytP4WuZeU63uPVc+qU+p+E7aqLMhHjs7H90m6OfEyQK/Q2EO+mC4zlmFvYmKlRZSnbUkoIWKzNOF1gi0S6l2m79zOteNE1/bkE463HpL09SgZSTR3bk1sZX4xcpIuY4lzuQ0WGQWcg+lD3jcis dhtOO5Cb gJr5A99mgD36AJtYu2xcEsqeYpTvKWSBdJYrGLu04wxfw5ATH9uoPltoUJKTKyBYI89Y84qJeoTdlo7Ld1cGgVxjYOFsMwE7FtI3utYl1UPwhH63ElTPA2qrX2D4OMDxRb9ZX1xNCUpF7tn5ey17TVsDFjk1Jv6NkbRqs5zTtv7bzKgL+fcaxOf34SyoTlIAVxzYOCx9QFMy6KeR7psCzpNFvlUr+VPJ33mjkZzqU/Z4iA2wS8jYejU2fhx3nbu51K2n49V4UXZsNE+HgIYZEEKYxXA== 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 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 > @@ -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); /me has been wondering more and more if we should just pass the iter directly to iomap_begin rather than make them play these container_of tricks... OTOH I think the whole point of this: ret = ops->iomap_begin(iter->inode, iter->pos, iter->len, iter->flags, &iter->iomap, &iter->srcmap); is to "avoid" allowing the iomap users to mess with the internals of the iomap iter... > 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); ...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? --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 > >