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 17AC0C48297 for ; Mon, 12 Feb 2024 10:24:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8D35F6B0074; Mon, 12 Feb 2024 05:24:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 85B266B0075; Mon, 12 Feb 2024 05:24:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6FC3E6B0078; Mon, 12 Feb 2024 05:24:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 5BD4A6B0074 for ; Mon, 12 Feb 2024 05:24:30 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 26D6C809B1 for ; Mon, 12 Feb 2024 10:24:30 +0000 (UTC) X-FDA: 81782767500.03.AEB2352 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf12.hostedemail.com (Postfix) with ESMTP id 1979A4000E for ; Mon, 12 Feb 2024 10:24:27 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=cU4TXmjb; spf=none (imf12.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707733468; 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=rjQFj2Y3qw5mwmHLRiMU4jGR0CXRoHG5WfGG9b74Q3A=; b=hW61T3PEwY6KsWWv5Q3PWTyW3wtgIGdaNLaQ1LtnZgPBcUIlaCGKFeWY2QvrCZfmKSy7fL HTH6OjEFv899r4yXNa5hS+BvfaRrFtGhehgp+MZ4H6RXtgD9LD1MUuYAlq11pDmL1Hl4YA 642BZAWCWYMdDJ6Br2fzHJy6o4q579c= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707733468; a=rsa-sha256; cv=none; b=b59luGbPogXclkybptX+9lMJzzdihztJ/Nj+bzKLvVMbclDqKexDTSWi+IMEAWSeGZb/MC 3SVDHssRPJq6MIiqbeWUIXSjbHuQR62VDd0PcSAqhNNmOwHO/lGwGfMCxUjFkqOV2J4xzF m4nKci72X9Zwj1QUJZPOq27gp6/b2iY= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=cU4TXmjb; spf=none (imf12.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; 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=rjQFj2Y3qw5mwmHLRiMU4jGR0CXRoHG5WfGG9b74Q3A=; b=cU4TXmjbQ8YvfC7Gfc1RedGceJ Nj46EdFUx5xoSvev+Uh4BQgqZ9PYjSYA8R+mWQItKpbzvniRq5InhuKK62Z+U/1jKU0tqDl3g278M fuPxpYzV934A1mAgdh6elHtOrQCPkkd0WuvYIFGyWupR4VzF5bGOuYhJvWrB1dUCgcjCEkOGFdY2k mDsG0ROIYyWy/9lD43cV2s4vO9UAldXJvp3WeXE1oTwki+pqrdahMa5w5QLzSZcUROEhiLjl14anp RWz39xL4+AD/11nI7O0Ni8kvXrWei6D76bGYnVBQQQQ/RmAHUEGWYu3GffRIfh85bD3WJ7t5sz7UE TsLNwc6g==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rZTU6-0000000Adzq-18Cf; Mon, 12 Feb 2024 10:24:22 +0000 Date: Mon, 12 Feb 2024 10:24:22 +0000 From: Matthew Wilcox To: Ritesh Harjani Cc: "Darrick J. Wong" , Zhang Yi , linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz, hch@infradead.org, zokeefe@google.com, yi.zhang@huawei.com, chengzhihao1@huawei.com, yukuai3@huawei.com, wangkefeng.wang@huawei.com Subject: Re: [RFC PATCH v3 00/26] ext4: use iomap for regular file's buffered IO path and enable large foilo Message-ID: References: <20240212061842.GB6180@frogsfrogsfrogs> <87ttmef3fp.fsf@doe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ttmef3fp.fsf@doe.com> X-Stat-Signature: c9hfym9awfpxze7iywgtuprjjx7o37ks X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 1979A4000E X-Rspam-User: X-HE-Tag: 1707733467-235240 X-HE-Meta: U2FsdGVkX1/JGLVSuczqRVqeGN82FZEhXNKDJpNGTSShXlQ97FxK/3qPs20RY96nDeoF1cix/pg8HgTTtdwcFpckSzlCITABQF9GzR4HphhtIik1ZOxfXqqNud0JV50bV2AuReQSjt6U+uJDhdBlYzFTt4TU+gvWKTGZ8e2FMzHMZ4S2//R253j5/k3T6kWpFJL64cS051oqYZbU6gVSAzm63+qt8DzUNtT/jryO/SgEa5E9iscHA6y3MikOJdh/Jj7Lp4oGLmNhJs8w7ModsMWxzPlPP1stcBtGyqnMfMagmEkHVE8jxTKK2qHnwoazqPw9VJXrt9e/zsjQSgzlOPlfeDISTa/J+UCgA9f4uunV/wkr+tzAmp6d5Zum/KcXjmiTQexF95xogcEdPohi3V9jPYP97PMHfPBEyKKh+kYxZvNm3n3zzYoXdksRaxAn3zXU9ptOpuJL+yXtKpwlFfqIYCBjUxCyYL+ZMoK70F/rRXlTdSQk59QvP3G1CNZP6UHj9wAc0Qe7LmaN8G0N5OmozR1rI1BrLPC0avLeIowwjDKQMkfQGAj/IddoTNs91+bHx2GgC7hdnuKRGxIWm787RXhP3A2Jj0GTXbzD1fn0t0g+WTulsNunpe1akoPcGTxDLvZUuai86mtgu7cZVx8z/xlaeEMEeBP5GHvYbW77UteYzNtaerP6tztBsk4Lvy0ipt/bAA3rr+1YFo2fBWPweg/+f1lcsaU/cABCccrVkeZlslnOHbX1HwH/Xhq9p7jlzbkp3HTzimkFvlfMe4WqO9ADHkGH7F0iXPbuFDiEws/JpPB2ZVEQmWJAGwgH0Tg4HrDoAU38uG/Les04zjLiX/ZgfCL8HFJKTgI/yLpwkIQG1/KYkSgvj2v0Nz09LHCgyda8du9uODc3qcxF0PuqLbuim4a7 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, Feb 12, 2024 at 02:46:10PM +0530, Ritesh Harjani wrote: > "Darrick J. Wong" writes: > > though iirc willy never got the performance to match because iomap > > Ohh, can you help me provide details on what performance benchmark was > run? I can try and run them when I rebase. I didn't run a benchmark, we just knew what would happen (on rotating storage anyway). > > didn't have a mechanism for the caller to tell it "run the IO now even > > though you don't have a complete page, because the indirect block is the > > next block after the 11th block". > > Do you mean this for a large folio? I still didn't get the problem you > are referring here. Can you please help me explain why could that be a > problem? A classic ext2 filesystem lays out a 16kB file like this (with 512 byte blocks): file offset disk block 0-6KiB 1000-1011 6KiB-16KiB 1013-1032 What's in block 1012? The indirect block! The block which tells ext2 that blocks 12-31 of the file are in disk blocks 1013-1032. So we can't issue the read for them until we've finished the read for block 1012. Buffer heads have a solution for this, BH_Boundary. ext2 sets it for block 11 which prompts mpage.c to submit the read immediately (see the various calls to buffer_boundary()). Then ext2 will submit the read for block 1012 and the two reads will be coalesced by the IO scheduler. So we still end up doing two reads instead of one, but that's unavoidable because fragmentation might have meant that 6KiB-16KiB were not stored at 1013-1032. There's no equivalent iomap solution. What needs to happen is: - iomap_folio_state->read_bytes_pending needs to be initialised to folio_size(), not 0. - Remove "ifs->read_bytes_pending += plen" from iomap_readpage_iter() - Subtract plen in the iomap_block_needs_zeroing() case - Submit a bio at the end of each iomap_readpage_iter() call Now iomap will behave the same way as mpage, only without needing a flag to do it (instead it will assume that the filesystem coalesces adjacent ranges, which it should do anyway for good performance).