[{"id":3677503,"web_url":"http://patchwork.ozlabs.org/comment/3677503/","msgid":"<ad867C8dlaQGLS97@infradead.org>","list_archive_url":null,"date":"2026-04-15T07:14:52","subject":"Re: [RFC PATCH] iomap: add fast read path for small direct I/O","submitter":{"id":178,"url":"http://patchwork.ozlabs.org/api/people/178/","name":"Christoph Hellwig","email":"hch@infradead.org"},"content":"On Tue, Apr 14, 2026 at 08:26:47PM +0800, Fengnan Chang wrote:\n> 1. Allocating the `bio` and `struct iomap_dio` together to avoid a\n>    separate kmalloc. However, because `struct iomap_dio` is relatively\n>    large and the main path is complex, this yielded almost no\n>    performance improvement.\n\nOne interesting bit here would be a slab for struct iomap_dio, and\nthe previously discussed per-cpu allocation of some form.\n\n> 2. Reducing unnecessary state resets in the iomap state machine (e.g.,\n>    skipping `iomap_iter_reset_iomap` where safe). This provided a ~5%\n>    IOPS boost, which is helpful but still falls far short of closing\n>    the gap with the raw block device.\n\nBut it already is a major improvement, and one that would apply outside\nof narrow special cases.  So I'd really like to see that patch.\n\n> The fast path is triggered when the request satisfies:\n> - Asynchronous READ request only for now.\n\nI think you really should handle synchronous reads as well.\n\n> - I/O size is <= inode blocksize (fits in a single block, no splits).\n\nMakes sense, and I suspect this is the main source of speedups.\n\n> - Aligned to the block device's logical block size.\n\nAll direct I/O requires this.\n\n> - No bounce buffering, fscrypt, or fsverity involved.\n> - No custom `iomap_dio_ops` (dops) registered by the filesystem.\n\nI'm really curious at what difference this makes.  It removes a few\nbranches, but should not have much of an effect while limiting the\napplicability a lot.\n\n> After this optimization, the heavy generic functions disappear from the\n> profile, replaced by a single streamlined execution path:\n>   4.83%  [kernel]  [k] iomap_dio_fast_read_async.isra.31\n> \n> With this patch, 4K random read IOPS on ext4 increases from 1.9M to\n> 2.3M.\n\nThat is still a lot slower than the block device path.  A big part of\nit should be the extent lookup and locking associated with it, but\nI'd expect things to be a bit better.  Do you have XFS version as well?\n\n> However, I am submitting this patch to validate whether this\n> optimization direction is correct and worth pursuing. I would appreciate\n> feedback on how to better integrate these ideas into the main iomap\n> execution path.\n\nI think a <= block size fast path makes a lot of sense, just like we\nhave a simple version on the block device, but it needs more work.\n\n> +struct iomap_dio_fast_read {\n> +\tstruct kiocb\t*iocb;\n> +\tsize_t\t\tsize;\n> +\tbool\t\tshould_dirty;\n> +\tstruct work_struct\twork;\n> +\tstruct bio\tbio ____cacheline_aligned_in_smp;\n\nDoes the cache line alignment matter here?  If yes, can you explain why\nin a comment?\n\n> +static struct bio_set iomap_dio_fast_read_pool;\n\nIn general I'd prefer to stick to simple as in the block device version\ninstead of fast.\n\n> +static void iomap_dio_fast_read_complete_work(struct work_struct *work)\n> +{\n> +\tstruct iomap_dio_fast_read *fr =\n> +\t\tcontainer_of(work, struct iomap_dio_fast_read, work);\n> +\tstruct kiocb *iocb = fr->iocb;\n> +\tstruct inode *inode = file_inode(iocb->ki_filp);\n> +\tbool should_dirty = fr->should_dirty;\n> +\tstruct bio *bio = &fr->bio;\n> +\tssize_t ret;\n> +\n> +\tWRITE_ONCE(iocb->private, NULL);\n> +\n> +\tif (likely(!bio->bi_status)) {\n> +\t\tret = fr->size;\n> +\t\tiocb->ki_pos += ret;\n> +\t} else {\n> +\t\tret = blk_status_to_errno(bio->bi_status);\n> +\t\tfserror_report_io(inode, FSERR_DIRECTIO_READ, iocb->ki_pos,\n> +\t\t\t\t  fr->size, ret, GFP_NOFS);\n> +\t}\n> +\n> +\tif (should_dirty) {\n> +\t\tbio_check_pages_dirty(bio);\n> +\t} else {\n> +\t\tbio_release_pages(bio, false);\n> +\t\tbio_put(bio);\n> +\t}\n> +\n> +\tinode_dio_end(inode);\n> +\n> +\ttrace_iomap_dio_complete(iocb, ret < 0 ? ret : 0, ret > 0 ? ret : 0);\n> +\tiocb->ki_complete(iocb, ret);\n\nThis is a lot of duplicate cork.  Can we somehow share it by passing\nmore arguments or embedding the simple context into the bigger one?\n\n> +static inline bool iomap_dio_fast_read_supported(struct kiocb *iocb,\n> +\t\t\t\t\t  struct iov_iter *iter,\n> +\t\t\t\t\t  unsigned int dio_flags,\n> +\t\t\t\t\t  size_t done_before)\n\nPlease stick to two-tab indents for prototype continuations, which is\nboth more readable and easier to modify later.\n\n> +\tif (count < bdev_logical_block_size(inode->i_sb->s_bdev))\n> +\t\treturn false;\n\nSub-sector reads (unlike writes) don't require any special handling, so\nI don't see why they are excluded.\n\n> +\tif (dio_flags & IOMAP_DIO_FSBLOCK_ALIGNED)\n> +\t\talignment = i_blocksize(inode);\n> +\telse\n> +\t\talignment = bdev_logical_block_size(inode->i_sb->s_bdev);\n> +\n> +\tif ((iocb->ki_pos | count) & (alignment - 1))\n> +\t\treturn false;\n\nFactor this into a helper?\n\n> +\tinode_dio_begin(inode);\n> +\n> +\tret = ops->iomap_begin(inode, iomi.pos, count, iomi.flags,\n> +\t\t\t       &iomi.iomap, &iomi.srcmap);\n> +\tif (ret) {\n> +\t\tinode_dio_end(inode);\n> +\t\treturn ret;\n> +\t}\n\nIf we can I'd much prefer avoiding the open coded iomap_begin\ninvocation, as that is a real maintenance burden.\n\n> +\n> +\tif (iomi.iomap.type != IOMAP_MAPPED ||\n> +\t    iomi.iomap.offset > iomi.pos ||\n> +\t    iomi.iomap.offset + iomi.iomap.length < iomi.pos + count ||\n> +\t    (iomi.iomap.flags & IOMAP_F_ANON_WRITE)) {\n\nIOMAP_F_ANON_WRITE (as the name implies) only applies to writes.\n\n> +\t\tret = -EAGAIN;\n\n-EAGAIN is a bad status code, as we already use to indicate that a\nnon-blocking read blocks.\n\n> +\tret = bio_iov_iter_get_pages(bio, iter,\n> +\t\t\t\t     bdev_logical_block_size(iomi.iomap.bdev) - 1);\n\nOverly long line.  Also this needs to use the calculated alignment\nvalue.\n\n> +\tif (unlikely(ret)) {\n> +\t\tbio_put(bio);\n> +\t\tgoto out_iomap_end;\n> +\t}\n> +\n> +\tif (bio->bi_iter.bi_size != count) {\n> +\t\tiov_iter_revert(iter, bio->bi_iter.bi_size);\n> +\t\tbio_release_pages(bio, false);\n> +\t\tbio_put(bio);\n> +\t\tret = -EAGAIN;\n> +\t\tgoto out_iomap_end;\n> +\t}\n\nShare the bio_put with a new goto label, and maybe also move all\nthe other cleanup code out of the main path into a label?\n\n> +\tif (!dops && iomap_dio_fast_read_supported(iocb, iter, dio_flags, done_before)) {\n\nOverly long line.  But we should not make the fast path conditional\non an option anyway.","headers":{"Return-Path":"\n <SRS0=6ZhM=CO=vger.kernel.org=linux-ext4+bounces-15841-patchwork-incoming=ozlabs.org@ozlabs.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linux-ext4@vger.kernel.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","patchwork-incoming@ozlabs.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256\n header.s=bombadil.20210309 header.b=RfC74fl5;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=ozlabs.org\n (client-ip=150.107.74.76; helo=mail.ozlabs.org;\n envelope-from=srs0=6zhm=co=vger.kernel.org=linux-ext4+bounces-15841-patchwork-incoming=ozlabs.org@ozlabs.org;\n receiver=patchwork.ozlabs.org)","gandalf.ozlabs.org;\n arc=pass smtp.remote-ip=\"2600:3c0a:e001:db::12fc:5321\"\n arc.chain=subspace.kernel.org","gandalf.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=infradead.org","gandalf.ozlabs.org;\n\tdkim=pass (2048-bit key;\n secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256\n header.s=bombadil.20210309 header.b=RfC74fl5;\n\tdkim-atps=neutral","gandalf.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-ext4+bounces-15841-patchwork-incoming=ozlabs.org@vger.kernel.org;\n receiver=ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org\n header.b=\"RfC74fl5\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=198.137.202.133","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=infradead.org","smtp.subspace.kernel.org;\n spf=none smtp.mailfrom=bombadil.srs.infradead.org"],"Received":["from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fwXVq1ldjz1yHM\n\tfor <incoming@patchwork.ozlabs.org>; Wed, 15 Apr 2026 17:16:02 +1000 (AEST)","from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3])\n\tby gandalf.ozlabs.org (Postfix) with ESMTP id 4fwXVp4qwfz4w2D\n\tfor <incoming@patchwork.ozlabs.org>; Wed, 15 Apr 2026 17:16:02 +1000 (AEST)","by gandalf.ozlabs.org (Postfix)\n\tid 4fwXVp4lx8z4wsP; Wed, 15 Apr 2026 17:16:02 +1000 (AEST)","from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby gandalf.ozlabs.org (Postfix) with ESMTPS id 4fwXVg3g0Lz4w2D\n\tfor <patchwork-incoming@ozlabs.org>; Wed, 15 Apr 2026 17:15:55 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id A6DCA305BFEA\n\tfor <patchwork-incoming@ozlabs.org>; Wed, 15 Apr 2026 07:14:58 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id D557B39B95C;\n\tWed, 15 Apr 2026 07:14:57 +0000 (UTC)","from bombadil.infradead.org (bombadil.infradead.org\n [198.137.202.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id CF43D296BD2;\n\tWed, 15 Apr 2026 07:14:53 +0000 (UTC)","from hch by bombadil.infradead.org with local (Exim 4.98.2 #2 (Red\n Hat Linux))\n\tid 1wCuSa-00000000hgG-1gw1;\n\tWed, 15 Apr 2026 07:14:52 +0000"],"ARC-Seal":["i=2; a=rsa-sha256; d=ozlabs.org; s=201707; t=1776237362; cv=pass;\n\tb=ZaPf6XuYpjbdzQ2Fkqm5I+LM1duNJksINM3hA1V3c9wSPnCRWcevKr3a5Xj3yb8koSePLT+4zcIuWbl1Wo/+Tye01v8cnWNTpyUR5/+jMS3ZAZBjiIjhX3q3/O6To5gQ7zK8utIKydZrM/939IdxUzIWK4CfMnBzfUeGgQdvLLyvTVhW03/KEn0cc1E1dqd195adn70Lll3BixA2PM4anFmo5nQXkMbT1PjDomo5kaNqLCEkkVGV55TW/rCsNUaDuMmZ1MySokDVEMBK3cV8jwbWhNgQznr+dfgJFKgkNwG7GXHF7fT04w2ne8/wTXN0AdMBg+MB9kq7ExRNMkMGyg==","i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776237297; cv=none;\n b=JIS1/xv2NkNtikJ6LT3u/+VseyAFTJAmdUMufcnDbVBBtid9r3EZ8/SynN7UnO7DmeJvWgAhYfqiE2XkAoXyBAn9I4si0KqS4WYKUpdjUiVxjHszbsRBuw2hprsD26t5ik9Vp73Ep1WYlC+7dFQBs1pVLFDwsyM3l7qHMInVRNY="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=ozlabs.org; s=201707;\n\tt=1776237362; c=relaxed/relaxed;\n\tbh=nMX+sZj8drE/99C18prapzNEOvBD+6iIMi/RWCeMSzY=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=HD+qafXkM+P0TeF3xt5ufOlaqT+P7zPXsxQlJ55GcKcSpcXE20vkw6VE1FlLBms4w56+tNNQW60CQO+KhN1cmFi3rHHWCTIuSG24v2SXfSlaVMt1taEwHA0aJzKHf+34SvKFtuTT+P7bkkq2h0CWYpGDGI9PHUBFKfg0sq7j12eIg2E3qW/vjT6VgM/igR8Of9xvVB+cd8CPs72iBV05qlWilAslqLEHcEBlprrPXx/W7Q67NyoY/sf7Id4S3EBm6j8Bbnkjse74Yza4j2z0WfaSjBkiaqC7jle5mLYu3T+9VhzNUxBlU0iFjLfcoE6AnntucpDfZqEeSQLnxdbfUg==","i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776237297; c=relaxed/simple;\n\tbh=LrHJhqCLpkudC12chwMsz3E0lmsl8hdf/QsiL+fDzJw=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=KQnx0tQdiLapnI1fpbTMilLjamRGTqL4NoiNxhOkr3ZXtXAXKOKJAoqXRSLb3v/9OhMiiEVXOPHyllpzJkX1zhKQ2+oVLB7YgkOeOaxmJM9tgewCj2L4Hav4kHkEY0XkQQg3JmmtIe8AEPLwEB+4Ur8TdC3XuTIYyOcwhxiTVSo="],"ARC-Authentication-Results":["i=2; gandalf.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=infradead.org;\n dkim=pass (2048-bit key;\n secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256\n header.s=bombadil.20210309 header.b=RfC74fl5; dkim-atps=neutral;\n spf=pass (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-ext4+bounces-15841-patchwork-incoming=ozlabs.org@vger.kernel.org;\n receiver=ozlabs.org) smtp.mailfrom=vger.kernel.org","i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=infradead.org;\n spf=none smtp.mailfrom=bombadil.srs.infradead.org;\n dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org\n header.b=RfC74fl5; arc=none smtp.client-ip=198.137.202.133"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version\n\t:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:\n\tContent-Transfer-Encoding:Content-ID:Content-Description;\n\tbh=nMX+sZj8drE/99C18prapzNEOvBD+6iIMi/RWCeMSzY=; b=RfC74fl5cE1YtHLCdbtF0Wnfsz\n\tfFCoaBRL66VmeO+0dWxl0u2479pS7f7GtH5S/ZNNcFaxN41dT9NvGAPh3zt3jq36tFs5btx55e7h1\n\ts2vFe9qmksPUsGmUstZ6JcdJibdcW8AmlPux09p2MDmJLF1btsjOqbfn4HrxJnavgo/RfUjzdgeyR\n\tgt4p+Al8qJg3mx8D4SNdOnQvjze8YwhblMCIkXHbO2H7R18Uyl8TnkGbKx7u1CwmL+uSWI6EO1c6X\n\t1f7oYAqxYrtumhzzp84zdK6DnZaa3fmCWEkaFzef5ka3u8xF04irjRyvYUfx4JRVkwnfB4RAcIFj2\n\tU6bJAWfg==;","Date":"Wed, 15 Apr 2026 00:14:52 -0700","From":"Christoph Hellwig <hch@infradead.org>","To":"Fengnan Chang <fengnanchang@gmail.com>","Cc":"brauner@kernel.org, djwong@kernel.org, linux-xfs@vger.kernel.org,\n\tlinux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,\n\tlidiangang@bytedance.com,\n\tFengnan Chang <changfengnan@bytedance.com>","Subject":"Re: [RFC PATCH] iomap: add fast read path for small direct I/O","Message-ID":"<ad867C8dlaQGLS97@infradead.org>","References":"<20260414122647.15686-1-changfengnan@bytedance.com>","Precedence":"bulk","X-Mailing-List":"linux-ext4@vger.kernel.org","List-Id":"<linux-ext4.vger.kernel.org>","List-Subscribe":"<mailto:linux-ext4+subscribe@vger.kernel.org>","List-Unsubscribe":"<mailto:linux-ext4+unsubscribe@vger.kernel.org>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20260414122647.15686-1-changfengnan@bytedance.com>","X-SRS-Rewrite":"SMTP reverse-path rewritten from <hch@infradead.org> by\n bombadil.infradead.org. See http://www.infradead.org/rpr.html","X-Spam-Status":"No, score=-1.2 required=5.0 tests=ARC_SIGNED,ARC_VALID,\n\tDKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DMARC_PASS,\n\tHEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,\n\tSPF_PASS autolearn=disabled version=4.0.1","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on gandalf.ozlabs.org"}},{"id":3677792,"web_url":"http://patchwork.ozlabs.org/comment/3677792/","msgid":"<ad_h0JMX2Jo-QODG@li-dc0c254c-257c-11b2-a85c-98b6c1322444.ibm.com>","list_archive_url":null,"date":"2026-04-15T19:06:56","subject":"Re: [RFC PATCH] iomap: add fast read path for small direct I/O","submitter":{"id":83422,"url":"http://patchwork.ozlabs.org/api/people/83422/","name":"Ojaswin Mujoo","email":"ojaswin@linux.ibm.com"},"content":"On Tue, Apr 14, 2026 at 08:26:47PM +0800, Fengnan Chang wrote:\n> When running 4K random read workloads on high-performance Gen5 NVMe\n> SSDs, the software overhead in the iomap direct I/O path\n> (__iomap_dio_rw) becomes a significant bottleneck.\n> \n> Using io_uring with poll mode for a 4K randread test on a raw block\n> device:\n> taskset -c 30 ./t/io_uring -p1 -d512 -b4096 -s32 -c32 -F1 -B1 -R1 -X1\n> -n1 -P1 /dev/nvme10n1\n> Result: ~3.2M IOPS\n> \n> Running the exact same workload on ext4 and XFS:\n> taskset -c 30 ./t/io_uring -p1 -d512 -b4096 -s32 -c32 -F1 -B1 -R1 -X1\n> -n1 -P1 /mnt/testfile\n> Result: ~1.9M IOPS\n\nHi Fengnan, interesting optimization! \nWhich test suite are you using here for the io_uring tests? \n> \n> Profiling the ext4 workload reveals that a significant portion of CPU\n> time is spent on memory allocation and the iomap state machine\n> iteration:\n>   5.33%  [kernel]  [k] __iomap_dio_rw\n>   3.26%  [kernel]  [k] iomap_iter\n>   2.37%  [kernel]  [k] iomap_dio_bio_iter\n>   2.35%  [kernel]  [k] kfree\n>   1.33%  [kernel]  [k] iomap_dio_complete\n\nHmm read is usually under a shared lock for inode as well as extent\nlookup so we should ideally not be blocking too much there. Can you\nshare a bit more detailed perf report. I'd be interested to see where\nin iomap_iter() are you seeing the regression?\n> \n> I attempted several incremental optimizations in the __iomap_dio_rw()\n> path to close the gap:\n> 1. Allocating the `bio` and `struct iomap_dio` together to avoid a\n>    separate kmalloc. However, because `struct iomap_dio` is relatively\n>    large and the main path is complex, this yielded almost no\n>    performance improvement.\n> 2. Reducing unnecessary state resets in the iomap state machine (e.g.,\n>    skipping `iomap_iter_reset_iomap` where safe). This provided a ~5%\n>    IOPS boost, which is helpful but still falls far short of closing\n>    the gap with the raw block device.\n> \n\n<...>\n\n>  \n> +static bool iomap_dio_fast_read_enabled = true;\n> +\n> +struct iomap_dio_fast_read {\n> +\tstruct kiocb\t*iocb;\n> +\tsize_t\t\tsize;\n> +\tbool\t\tshould_dirty;\n> +\tstruct work_struct\twork;\n> +\tstruct bio\tbio ____cacheline_aligned_in_smp;\n\nAs Christoph pointed out, were you seeing any performance loss due to\nnot aligning to cacheline? Architectures like powerpc have a 128byte\ncacheline and we could end up wasting significant space here.\n\n> +};\n> +\n> +static struct bio_set iomap_dio_fast_read_pool;\n> +\n> +static void iomap_dio_fast_read_complete_work(struct work_struct *work)\n> +{\n\n<...>\n\n> +\n> +static inline bool iomap_dio_fast_read_supported(struct kiocb *iocb,\n> +\t\t\t\t\t  struct iov_iter *iter,\n> +\t\t\t\t\t  unsigned int dio_flags,\n> +\t\t\t\t\t  size_t done_before)\n> +{\n> +\tstruct inode *inode = file_inode(iocb->ki_filp);\n> +\tsize_t count = iov_iter_count(iter);\n> +\tunsigned int alignment;\n> +\n> +\tif (!iomap_dio_fast_read_enabled)\n> +\t\treturn false;\n> +\tif (iov_iter_rw(iter) != READ)\n> +\t\treturn false;\n> +\n> +\t/*\n> +\t * Fast read is an optimization for small IO. Filter out large IO early\n> +\t * as it's the most common case to fail for typical direct IO workloads.\n> +\t */\n> +\tif (count > inode->i_sb->s_blocksize)\n> +\t\treturn false;\n> +\n> +\tif (is_sync_kiocb(iocb) || done_before)\n\nDid you try this for sync reads as well? I think we should be seeing\nsimilar benefits with sync reads too. Further, if the fast path helps us\nreduce the critical section under inode lock, it could be a good win for\nmixed read write workloads.\n\n> +\t\treturn false;\n> +\tif (dio_flags & (IOMAP_DIO_FORCE_WAIT | IOMAP_DIO_BOUNCE))\n> +\t\treturn false;\n> +\tif (iocb->ki_pos + count > i_size_read(inode))\n> +\t\treturn false;\n> +\tif (IS_ENCRYPTED(inode) || fsverity_active(inode))\n> +\t\treturn false;\n> +\n> +\tif (count < bdev_logical_block_size(inode->i_sb->s_bdev))\n> +\t\treturn false;\n> +\n> +\tif (dio_flags & IOMAP_DIO_FSBLOCK_ALIGNED)\n> +\t\talignment = i_blocksize(inode);\n> +\telse\n> +\t\talignment = bdev_logical_block_size(inode->i_sb->s_bdev);\n> +\n> +\tif ((iocb->ki_pos | count) & (alignment - 1))\n> +\t\treturn false;\n> +\n> +\treturn true;\n> +}\n> +\n> +static ssize_t iomap_dio_fast_read_async(struct kiocb *iocb,\n\n<...>\n\n> +static ssize_t fast_read_enable_store(struct kobject *kobj,\n> +\t\t\t\t      struct kobj_attribute *attr,\n> +\t\t\t\t      const char *buf, size_t count)\n> +{\n> +\tbool enable;\n> +\tint ret;\n> +\n> +\tret = kstrtobool(buf, &enable);\n> +\tif (ret)\n> +\t\treturn ret;\n> +\n> +\tiomap_dio_fast_read_enabled = enable;\n> +\treturn count;\n> +}\n> +\n> +static struct kobj_attribute fast_read_enable_attr =\n> +\t__ATTR(fast_read_enable, 0644, fast_read_enable_show, fast_read_enable_store);\n> +\n> +static struct kobject *iomap_kobj;\n> +\n> +static int __init iomap_dio_sysfs_init(void)\n\nSince we do more than sysfs work here, maybe we can have a more generic\nname like iomap_dio_init(void) or iomap_dio_fast/simple_read_init().\n\n\n> +{\n> +\tint ret;\n> +\n> +\tret = bioset_init(&iomap_dio_fast_read_pool, 4,\n> +\t\t\t  offsetof(struct iomap_dio_fast_read, bio),\n> +\t\t\t  BIOSET_NEED_BVECS | BIOSET_PERCPU_CACHE);\n> +\tif (ret)\n> +\t\treturn ret;\n> +\n> +\tiomap_kobj = kobject_create_and_add(\"iomap\", fs_kobj);\n> +\tif (!iomap_kobj) {\n> +\t\tbioset_exit(&iomap_dio_fast_read_pool);\n> +\t\treturn -ENOMEM;\n> +\t}\n> +\n> +\tif (sysfs_create_file(iomap_kobj, &fast_read_enable_attr.attr)) {\n> +\t\tkobject_put(iomap_kobj);\n> +\t\tbioset_exit(&iomap_dio_fast_read_pool);\n> +\t\treturn -ENOMEM;\n> +\t}\n> +\n> +\treturn 0;\n> +}\n> +fs_initcall(iomap_dio_sysfs_init);\n> -- \n\nRegards,\nojaswin\n\n> 2.39.5 (Apple Git-154)\n>","headers":{"Return-Path":"\n <SRS0=yhPV=CO=vger.kernel.org=linux-ext4+bounces-15849-patchwork-incoming=ozlabs.org@ozlabs.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linux-ext4@vger.kernel.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","patchwork-incoming@ozlabs.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256\n header.s=pp1 header.b=isyOdkcM;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=ozlabs.org\n (client-ip=2404:9400:2221:ea00::3; helo=mail.ozlabs.org;\n envelope-from=srs0=yhpv=co=vger.kernel.org=linux-ext4+bounces-15849-patchwork-incoming=ozlabs.org@ozlabs.org;\n receiver=patchwork.ozlabs.org)","gandalf.ozlabs.org;\n arc=pass smtp.remote-ip=\"2600:3c09:e001:a7::12fc:5321\"\n arc.chain=subspace.kernel.org","gandalf.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=linux.ibm.com","gandalf.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256\n header.s=pp1 header.b=isyOdkcM;\n\tdkim-atps=neutral","gandalf.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c09:e001:a7::12fc:5321; helo=sto.lore.kernel.org;\n envelope-from=linux-ext4+bounces-15849-patchwork-incoming=ozlabs.org@vger.kernel.org;\n receiver=ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com\n header.b=\"isyOdkcM\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=148.163.158.5","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.ibm.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=linux.ibm.com"],"Received":["from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fwrHn1tWKz1yHc\n\tfor <incoming@patchwork.ozlabs.org>; Thu, 16 Apr 2026 05:07:32 +1000 (AEST)","from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3])\n\tby gandalf.ozlabs.org (Postfix) with ESMTP id 4fwrHf5H5qz4wsp\n\tfor <incoming@patchwork.ozlabs.org>; Thu, 16 Apr 2026 05:07:26 +1000 (AEST)","by gandalf.ozlabs.org (Postfix)\n\tid 4fwrHf4vcdz4x0Q; Thu, 16 Apr 2026 05:07:26 +1000 (AEST)","from sto.lore.kernel.org (sto.lore.kernel.org\n [IPv6:2600:3c09:e001:a7::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest\n SHA256)\n\t(No client certificate requested)\n\tby gandalf.ozlabs.org (Postfix) with ESMTPS id 4fwrHb0PZKz4wsp\n\tfor <patchwork-incoming@ozlabs.org>; Thu, 16 Apr 2026 05:07:23 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sto.lore.kernel.org (Postfix) with ESMTP id 7A9F13019058\n\tfor <patchwork-incoming@ozlabs.org>; Wed, 15 Apr 2026 19:07:19 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 039CA383C9E;\n\tWed, 15 Apr 2026 19:07:18 +0000 (UTC)","from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com\n [148.163.158.5])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 761BF32FA30;\n\tWed, 15 Apr 2026 19:07:16 +0000 (UTC)","from pps.filterd (m0360072.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id\n 63FHYjIu1804718;\n\tWed, 15 Apr 2026 19:07:04 GMT","from ppma11.dal12v.mail.ibm.com\n (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219])\n\tby mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4dh89k9844-1\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);\n\tWed, 15 Apr 2026 19:07:03 +0000 (GMT)","from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1])\n\tby ppma11.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id\n 63FHf6h1003253;\n\tWed, 15 Apr 2026 19:07:03 GMT","from smtprelay06.fra02v.mail.ibm.com ([9.218.2.230])\n\tby ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 4djbh918f2-1\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);\n\tWed, 15 Apr 2026 19:07:03 +0000","from smtpav02.fra02v.mail.ibm.com (smtpav02.fra02v.mail.ibm.com\n [10.20.54.101])\n\tby smtprelay06.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n 63FJ71AC31850958\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);\n\tWed, 15 Apr 2026 19:07:01 GMT","from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 6501720043;\n\tWed, 15 Apr 2026 19:07:01 +0000 (GMT)","from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 2655620040;\n\tWed, 15 Apr 2026 19:06:59 +0000 (GMT)","from li-dc0c254c-257c-11b2-a85c-98b6c1322444.ibm.com (unknown\n [9.39.25.126])\n\tby smtpav02.fra02v.mail.ibm.com (Postfix) with ESMTPS;\n\tWed, 15 Apr 2026 19:06:58 +0000 (GMT)"],"ARC-Seal":["i=2; a=rsa-sha256; d=ozlabs.org; s=201707; t=1776280046; cv=pass;\n\tb=yeoAfqPRry8JTvDTVck1AMuE1KUbkvSaUn8dOulwYCgtvYN9TU8Qr9oDSMMlHT4NHcT5aRoBG4iMbmXd1KIX16q3BSW6QMJRxwCrrrVlpmfACtTi2pKJR0m7FKo2xrWwaR71c5qKgh/r1DIfLQZSL3+3+KQwR7Rj6fW9kYlUdTGP6k9o833cFU/Uqj3tFNf+Vb66NQbkqsHdKRq4AcBJHNoqC3367+dWP8gEZSGOqSF7ryka09ryQsWT2crgRdS5O/rlV/xF3VbQeI5oC/3EuskS/wGCyjmjDgygJJUNEUSIU4Fhjtoyl7BF2fAwEmEN9JbIqWCiLtAKC5msyCo6xg==","i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776280037; cv=none;\n b=noDY68YHFy3VrOWroNNVylVMMQSgG/6iMWKv+qWmSiu8hQVp7S/Tq0hGTE7HL6eIXCo21ZTt5AjHJVAXx0F3S7um0jidTqrEAI0AC3Gy4J6yxfDIUa9+Mq8fF/b0zGgMdfJcMUU/5k642kE/wIxobzLd3KaSH+5FNav/Ie/CFxY="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=ozlabs.org; s=201707;\n\tt=1776280046; c=relaxed/relaxed;\n\tbh=KmXnolMrf461wgQ0WQx/3QyawZRBSD40hzSE7LLThEQ=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=jxpqa/ZEOAnRjv2B9wst91j9EIsb9dM1/HSNUcY+OPHqU02M1iwGfhs3YQit7/6z5ms0hm4hRxJJZxHt7k1UTTcSgtmk0voA+nUTWF261ij8v9ioT8L6TISWw1hNqn8lpqwl5ptMAg1ucEej2fjorxV/R0/Sjw6u8Icl8Z18yWPnkWLKvA71LOh5QiVJSdNFA1H1ugKBvtNsHsbLG1n/JMzAiEDqMgOrqqfIe0+4p+3Y5mtNnq9FU3watjTpRFeh3sLaSifzkSY+fLMoorTwJqBB70M8B9kOKilwQxcyp3gdJSVdAezRAumEuEjflw5Ndjztdw+1hWL55deb4McVqw==","i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776280037; c=relaxed/simple;\n\tbh=2drBqYrF35CpWaxOSZSKY1O/3qDFuiV8G7DRGAsP0bc=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=aA76PHUXbOzt0cKZKN+fdAgYFdC+3qmN89HY0+ncAHXPOipcKN4IAS0+I1NP5olAJ3nMBv65A0moBuk/haBHTQ24fDya1g0ZhKplhfqAO4cbTCeQf0IbTkTW/AHxS4YDA6cYUNLF0LX5u9qvTgceHo9awcQr9Hq7U9/QxgtNDGw="],"ARC-Authentication-Results":["i=2; gandalf.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=linux.ibm.com;\n dkim=pass (2048-bit key;\n unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256\n header.s=pp1 header.b=isyOdkcM; dkim-atps=neutral;\n spf=pass (client-ip=2600:3c09:e001:a7::12fc:5321; helo=sto.lore.kernel.org;\n envelope-from=linux-ext4+bounces-15849-patchwork-incoming=ozlabs.org@vger.kernel.org;\n receiver=ozlabs.org) smtp.mailfrom=vger.kernel.org","i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.ibm.com;\n spf=pass smtp.mailfrom=linux.ibm.com;\n dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com\n header.b=isyOdkcM; arc=none smtp.client-ip=148.163.158.5"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc\n\t:content-type:date:from:in-reply-to:message-id:mime-version\n\t:references:subject:to; s=pp1; bh=KmXnolMrf461wgQ0WQx/3QyawZRBSD\n\t40hzSE7LLThEQ=; b=isyOdkcM2EBxTsj3VcLyIVaXzVRk/WsQn4ib+MR9j7Re0R\n\tdc2N090cZWYdOPvYx4yVNvyWkWROlyITdUEjJopUwr0xeEuGphQxEZgMh/CNrupo\n\tHlTSGZdKCl76+ujf53Eb4ewhQajpitto/CzFmzilbBvTbBqeOWyLFiJT4kBkNJSS\n\t5s84QISpAdE+UdvjiV3l01qEBLuFBbfdN9U/yy7V+lBgq0oiX3/vflP/rEQ+LM6D\n\tZwCOMWPW6Xgc/ANUJxOtzyhVtCHkQc3Wv5cSXmLJ+4e+e7KoaX0UCCSzpE39ZSSl\n\tJgyIWoVINTXLbJL5acK3g2FYLb2ZstHB3BfkzTfw==","Date":"Thu, 16 Apr 2026 00:36:56 +0530","From":"Ojaswin Mujoo <ojaswin@linux.ibm.com>","To":"Fengnan Chang <fengnanchang@gmail.com>","Cc":"brauner@kernel.org, djwong@kernel.org, linux-xfs@vger.kernel.org,\n        linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,\n        lidiangang@bytedance.com, Fengnan Chang <changfengnan@bytedance.com>","Subject":"Re: [RFC PATCH] iomap: add fast read path for small direct I/O","Message-ID":"<ad_h0JMX2Jo-QODG@li-dc0c254c-257c-11b2-a85c-98b6c1322444.ibm.com>","References":"<20260414122647.15686-1-changfengnan@bytedance.com>","Precedence":"bulk","X-Mailing-List":"linux-ext4@vger.kernel.org","List-Id":"<linux-ext4.vger.kernel.org>","List-Subscribe":"<mailto:linux-ext4+subscribe@vger.kernel.org>","List-Unsubscribe":"<mailto:linux-ext4+unsubscribe@vger.kernel.org>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20260414122647.15686-1-changfengnan@bytedance.com>","X-TM-AS-GCONF":"00","X-Proofpoint-Reinject":"loops=2 maxloops=12","X-Proofpoint-GUID":"-Mb5QKdULcvu1jiTyxPQJfrulZhJmqdT","X-Proofpoint-Spam-Details-Enc":"AW1haW4tMjYwNDE1MDE3NSBTYWx0ZWRfX0HUc6XcLtg+b\n 1qyPgN+Yv32rZtv6uE2JlkxkH6UBitRf8vAzwEoE1gPCkm1rDKqNunyT/sK187RGmo4PrOgkMsX\n 3lAQVqtgnhyC5ZWmJ0JCfseCACgU8CWF8NKr3vyw35DIU6JQegmbiSjYlxpKBQa5AX5RuF63+cz\n LeL8YwhfXmZ1hPsSUPzlIQxYMgU1rbul7I7LM+/ng/SCHsGxkx+J41PRTdbkxV53nzvJtIfrn+T\n tgWCu8E+wXUu3LlAr/97N/aN6SURZXuy1c1+4FRSimwqmyNocT7JWoVPTc40yS5pzWC7ZrUH6M1\n paioxkjzmxIqaBbcSQMH78z+kc1de7brehc9hjztu7KKj+OYNMn36mbOKcT+HFXzGSuOiDFL3x2\n fTBpEy/sLXRgUE89Ps8qvd7aBb1pmyydpHX0JA97neng/B/JJnOxy7ySW2yDioNholmqcC8reXd\n WlqE+9cncn7Gs3nqALQ==","X-Proofpoint-ORIG-GUID":"eYR6jZ15r0JOPE8ZgLM82s5KLMjN819K","X-Authority-Analysis":"v=2.4 cv=W60IkxWk c=1 sm=1 tr=0 ts=69dfe1d8 cx=c_pps\n a=aDMHemPKRhS1OARIsFnwRA==:117 a=aDMHemPKRhS1OARIsFnwRA==:17\n a=kj9zAlcOel0A:10 a=A5OVakUREuEA:10 a=VkNPw1HP01LnGYTKEx00:22\n a=RnoormkPH1_aCDwRdu11:22 a=RzCfie-kr_QcCd8fBx8p:22 a=yw5_ploFJTDS1x3vb8oA:9\n a=CjuIK1q_8ugA:10","X-Proofpoint-Virus-Version":"vendor=baseguard\n engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49\n definitions=2026-04-15_01,2026-04-13_04,2025-10-01_01","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n impostorscore=0 clxscore=1011 priorityscore=1501 spamscore=0 bulkscore=0\n adultscore=0 phishscore=0 lowpriorityscore=0 suspectscore=0 malwarescore=0\n classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0\n reason=mlx scancount=1 engine=8.22.0-2604070000 definitions=main-2604150175","X-Spam-Status":"No, score=-1.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,\n\tDKIM_SIGNED,DKIM_VALID,DMARC_PASS,HEADER_FROM_DIFFERENT_DOMAINS,\n\tMAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=disabled\n\tversion=4.0.1","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on gandalf.ozlabs.org"}},{"id":3677908,"web_url":"http://patchwork.ozlabs.org/comment/3677908/","msgid":"<d9210bcdf73fbe1ac8b6ec132865609a3ed68688.eee197c0.e67e.40c8.bd15.8fab5bbb42db@bytedance.com>","list_archive_url":null,"date":"2026-04-16T03:16:23","subject":"Re: [RFC PATCH] iomap: add fast read path for small direct I/O","submitter":{"id":85004,"url":"http://patchwork.ozlabs.org/api/people/85004/","name":"changfengnan","email":"changfengnan@bytedance.com"},"content":"> From: \"Christoph Hellwig\"<hch@infradead.org>\n> Date:  Wed, Apr 15, 2026, 15:15\n> Subject:  Re: [RFC PATCH] iomap: add fast read path for small direct I/O\n> To: \"Fengnan Chang\"<fengnanchang@gmail.com>\n> Cc: <brauner@kernel.org>, <djwong@kernel.org>, <linux-xfs@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>, <linux-ext4@vger.kernel.org>, <lidiangang@bytedance.com>, \"Fengnan Chang\"<changfengnan@bytedance.com>\n> On Tue, Apr 14, 2026 at 08:26:47PM +0800, Fengnan Chang wrote:\n> > 1. Allocating the `bio` and `struct iomap_dio` together to avoid a\n> >    separate kmalloc. However, because `struct iomap_dio` is relatively\n> >    large and the main path is complex, this yielded almost no\n> >    performance improvement.\n> \n> One interesting bit here would be a slab for struct iomap_dio, and\n> the previously discussed per-cpu allocation of some form.\nHi Christoph:\nThank you for your thorough review; it has given me greater confidence\nthat we are on the right path. This patch still needs a lot of work to be\nperfected,  I hope it will be worth it.\nYes, but use a new slab for struct iomap_dio doesn't help.\n\n> \n> > 2. Reducing unnecessary state resets in the iomap state machine (e.g.,\n> >    skipping `iomap_iter_reset_iomap` where safe). This provided a ~5%\n> >    IOPS boost, which is helpful but still falls far short of closing\n> >    the gap with the raw block device.\n> \n> But it already is a major improvement, and one that would apply outside\n> of narrow special cases.  So I'd really like to see that patch.\nYou can see this in:\nhttps://lore.kernel.org/linux-fsdevel/20260416030642.26744-1-changfengnan@bytedance.com/T/#u\n> \n> > The fast path is triggered when the request satisfies:\n> > - Asynchronous READ request only for now.\n> \n> I think you really should handle synchronous reads as well.\nI'll include support for it in the next version.\n> \n> > - I/O size is <= inode blocksize (fits in a single block, no splits).\n> \n> Makes sense, and I suspect this is the main source of speedups.\n> \n> > - Aligned to the block device's logical block size.\n> \n> All direct I/O requires this.\n> \n> > - No bounce buffering, fscrypt, or fsverity involved.\n> > - No custom `iomap_dio_ops` (dops) registered by the filesystem.\n> \n> I'm really curious at what difference this makes.  It removes a few\n> branches, but should not have much of an effect while limiting the\n> applicability a lot.\nYes, the impact shouldn’t be significant. \nSince this is just a RFC version to confirm that I’m on the right path, there\nare many aspects that haven’t been fully thought through yet. I haven’t\ntested these scenarios yet, but I’ll add support for them later to\ncheck  exactly what the impact is.\n> \n> > After this optimization, the heavy generic functions disappear from the\n> > profile, replaced by a single streamlined execution path:\n> >   4.83%  [kernel]  [k] iomap_dio_fast_read_async.isra.31\n> > \n> > With this patch, 4K random read IOPS on ext4 increases from 1.9M to\n> > 2.3M.\n> \n> That is still a lot slower than the block device path.  A big part of\n> it should be the extent lookup and locking associated with it, but\n> I'd expect things to be a bit better.  Do you have XFS version as well?\nYes, still a lot slower, I believe the other reason is due to the lookup of\nthe extent mapping.\nXFS and ext4 perform similarly， 1.92M IOPS to 2.32M IOPS. \n\n> \n> > However, I am submitting this patch to validate whether this\n> > optimization direction is correct and worth pursuing. I would appreciate\n> > feedback on how to better integrate these ideas into the main iomap\n> > execution path.\n> \n> I think a <= block size fast path makes a lot of sense, just like we\n> have a simple version on the block device, but it needs more work.\nAgree, I came up with this patch after being inspired by the way block\ndevices are handled. \n\n> \n> > +struct iomap_dio_fast_read {\n> > +        struct kiocb        *iocb;\n> > +        size_t                size;\n> > +        bool                should_dirty;\n> > +        struct work_struct        work;\n> > +        struct bio        bio ____cacheline_aligned_in_smp;\n> \n> Does the cache line alignment matter here?  If yes, can you explain why\n> in a comment?\n\nI copy this from struct blkdev_dio , I'll do some test to verfiy. \n> \n> > +static struct bio_set iomap_dio_fast_read_pool;\n> \n> In general I'd prefer to stick to simple as in the block device version\n> instead of fast.\n\nSimple is better name.\n> \n> > +static void iomap_dio_fast_read_complete_work(struct work_struct *work)\n> > +{\n> > +        struct iomap_dio_fast_read *fr =\n> > +                container_of(work, struct iomap_dio_fast_read, work);\n> > +        struct kiocb *iocb = fr->iocb;\n> > +        struct inode *inode = file_inode(iocb->ki_filp);\n> > +        bool should_dirty = fr->should_dirty;\n> > +        struct bio *bio = &fr->bio;\n> > +        ssize_t ret;\n> > +\n> > +        WRITE_ONCE(iocb->private, NULL);\n> > +\n> > +        if (likely(!bio->bi_status)) {\n> > +                ret = fr->size;\n> > +                iocb->ki_pos += ret;\n> > +        } else {\n> > +                ret = blk_status_to_errno(bio->bi_status);\n> > +                fserror_report_io(inode, FSERR_DIRECTIO_READ, iocb->ki_pos,\n> > +                                  fr->size, ret, GFP_NOFS);\n> > +        }\n> > +\n> > +        if (should_dirty) {\n> > +                bio_check_pages_dirty(bio);\n> > +        } else {\n> > +                bio_release_pages(bio, false);\n> > +                bio_put(bio);\n> > +        }\n> > +\n> > +        inode_dio_end(inode);\n> > +\n> > +        trace_iomap_dio_complete(iocb, ret < 0 ? ret : 0, ret > 0 ? ret : 0);\n> > +        iocb->ki_complete(iocb, ret);\n> \n> This is a lot of duplicate cork.  Can we somehow share it by passing\n> more arguments or embedding the simple context into the bigger one?\n\nI'll try. There are still many issues below, which I will address in the next version.\n> \n> > +static inline bool iomap_dio_fast_read_supported(struct kiocb *iocb,\n> > +                                          struct iov_iter *iter,\n> > +                                          unsigned int dio_flags,\n> > +                                          size_t done_before)\n> \n> Please stick to two-tab indents for prototype continuations, which is\n> both more readable and easier to modify later.\nGet.\n> \n> > +        if (count < bdev_logical_block_size(inode->i_sb->s_bdev))\n> > +                return false;\n> \n> Sub-sector reads (unlike writes) don't require any special handling, so\n> I don't see why they are excluded.\nAgree, Sub-sector reads can handle too.\n\n> \n> > +        if (dio_flags & IOMAP_DIO_FSBLOCK_ALIGNED)\n> > +                alignment = i_blocksize(inode);\n> > +        else\n> > +                alignment = bdev_logical_block_size(inode->i_sb->s_bdev);\n> > +\n> > +        if ((iocb->ki_pos | count) & (alignment - 1))\n> > +                return false;\n> \n> Factor this into a helper?\nGet.\n> \n> > +        inode_dio_begin(inode);\n> > +\n> > +        ret = ops->iomap_begin(inode, iomi.pos, count, iomi.flags,\n> > +                               &iomi.iomap, &iomi.srcmap);\n> > +        if (ret) {\n> > +                inode_dio_end(inode);\n> > +                return ret;\n> > +        }\n> \n> If we can I'd much prefer avoiding the open coded iomap_begin\n> invocation, as that is a real maintenance burden.\nIt seems we need introduce a new helper to do this.\n\n> \n> > +\n> > +        if (iomi.iomap.type != IOMAP_MAPPED ||\n> > +            iomi.iomap.offset > iomi.pos ||\n> > +            iomi.iomap.offset + iomi.iomap.length < iomi.pos + count ||\n> > +            (iomi.iomap.flags & IOMAP_F_ANON_WRITE)) {\n> \n> IOMAP_F_ANON_WRITE (as the name implies) only applies to writes.\n> \n> > +                ret = -EAGAIN;\n> \n> -EAGAIN is a bad status code, as we already use to indicate that a\n> non-blocking read blocks.\nAgree.\n\n> \n> > +        ret = bio_iov_iter_get_pages(bio, iter,\n> > +                                     bdev_logical_block_size(iomi.iomap.bdev) - 1);\n> \n> Overly long line.  Also this needs to use the calculated alignment\n> value.\nGet.\n> \n> > +        if (unlikely(ret)) {\n> > +                bio_put(bio);\n> > +                goto out_iomap_end;\n> > +        }\n> > +\n> > +        if (bio->bi_iter.bi_size != count) {\n> > +                iov_iter_revert(iter, bio->bi_iter.bi_size);\n> > +                bio_release_pages(bio, false);\n> > +                bio_put(bio);\n> > +                ret = -EAGAIN;\n> > +                goto out_iomap_end;\n> > +        }\n> \n> Share the bio_put with a new goto label, and maybe also move all\n> the other cleanup code out of the main path into a label?\nGet.\n> \n> > +        if (!dops && iomap_dio_fast_read_supported(iocb, iter, dio_flags, done_before)) {\n> \n> Overly long line.  But we should not make the fast path conditional\n> on an option anyway.\nGet.\n>","headers":{"Return-Path":"\n <SRS0=HCFE=CP=vger.kernel.org=linux-ext4+bounces-15856-patchwork-incoming=ozlabs.org@ozlabs.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linux-ext4@vger.kernel.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","patchwork-incoming@ozlabs.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=bytedance.com header.i=@bytedance.com\n header.a=rsa-sha256 header.s=2212171451 header.b=QyKof4OH;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=ozlabs.org\n (client-ip=2404:9400:2221:ea00::3; helo=mail.ozlabs.org;\n envelope-from=srs0=hcfe=cp=vger.kernel.org=linux-ext4+bounces-15856-patchwork-incoming=ozlabs.org@ozlabs.org;\n receiver=patchwork.ozlabs.org)","gandalf.ozlabs.org;\n arc=pass smtp.remote-ip=172.234.253.10 arc.chain=subspace.kernel.org","gandalf.ozlabs.org;\n dmarc=pass (p=quarantine dis=none) header.from=bytedance.com","gandalf.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=bytedance.com header.i=@bytedance.com\n header.a=rsa-sha256 header.s=2212171451 header.b=QyKof4OH;\n\tdkim-atps=neutral","gandalf.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=linux-ext4+bounces-15856-patchwork-incoming=ozlabs.org@vger.kernel.org;\n receiver=ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com\n header.b=\"QyKof4OH\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=209.127.230.112","smtp.subspace.kernel.org;\n dmarc=pass (p=quarantine dis=none) header.from=bytedance.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=bytedance.com"],"Received":["from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fx38P6l8Rz1yG9\n\tfor <incoming@patchwork.ozlabs.org>; Thu, 16 Apr 2026 13:16:53 +1000 (AEST)","from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3])\n\tby gandalf.ozlabs.org (Postfix) with ESMTP id 4fx38P5f3Jz4wM8\n\tfor <incoming@patchwork.ozlabs.org>; Thu, 16 Apr 2026 13:16:53 +1000 (AEST)","by gandalf.ozlabs.org (Postfix)\n\tid 4fx38P5VLWz4wTD; Thu, 16 Apr 2026 13:16:53 +1000 (AEST)","from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest\n SHA256)\n\t(No client certificate requested)\n\tby gandalf.ozlabs.org (Postfix) with ESMTPS id 4fx38J4Phbz4wM8\n\tfor <patchwork-incoming@ozlabs.org>; Thu, 16 Apr 2026 13:16:48 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 4A20D30ABC85\n\tfor <patchwork-incoming@ozlabs.org>; Thu, 16 Apr 2026 03:16:43 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 4FFEF233723;\n\tThu, 16 Apr 2026 03:16:42 +0000 (UTC)","from va-1-112.ptr.blmpb.com (va-1-112.ptr.blmpb.com\n [209.127.230.112])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id CE14A2D7BF\n\tfor <linux-ext4@vger.kernel.org>; Thu, 16 Apr 2026 03:16:39 +0000 (UTC)"],"ARC-Seal":["i=2; a=rsa-sha256; d=ozlabs.org; s=201707; t=1776309413; cv=pass;\n\tb=iha9sxopnOsuToGOCuPgdh9O/JS0SbUuQhnOzFsN+zX9vaThy2Odhg0GvbAv/50tgU4WYkHgMmpWf7JaKSbiVtZfiY1uOcu5Fj8z8Kg1bwdLc6KqPGuPznA4FVekhSPoLmQHXhgCSO96uhFl9tsduZPkaA21dkNPRQRBgANcvR7l14RtQzhXpGwKbnl7Mwl8IjMncJm5qvH1gcIOn3tMnXudd+7pgV/ToNm/KQ1xHiwKJw4GScoItVUlqe1reazfvMFqaTlPsu3AZJFxGzOx5WEs8Ai2+ns10tXk2ALybFzFlyXYKuhiVKKxpZHJUKfdYQ0UfU2Nfnh7K57GZYKpGQ==","i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776309402; cv=none;\n b=HJkmPwY4jc69g6c3SQUmherhopiixG0+yj/+c3A7sSFRsPj/y1Acvq5HSRbspxNampriyK0wQXMjF5kCOWMZTjJFLihdRmKv9PzUelT3ZCNXbT5+A+cIM6rPxy4JiTqFDRsEQUG8Rh+Q1+nMGXaHtIzVc3T6Ic/Fp9m5dikwnjk="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=ozlabs.org; s=201707;\n\tt=1776309413; c=relaxed/relaxed;\n\tbh=UX7ckDv0VlBHbW/LbC9WYb59J3AtFFa+/7fccWGzgeM=;\n\th=In-Reply-To:References:Cc:From:To:Subject:Mime-Version:\n\t Content-Type:Date:Message-Id;\n b=SMhuikAP6n3pCzhu+18EI3zluqv9blE7kCdG9E0sE9R6EquSZwuKeKqnji0eLZEIGmxCaD/25BBb2DK33z6x+GJkxfJR6Fn3/eN6GXOvzoepJHIoa0Zgj3QmnzAfJmVskCEz/OxO2ufX0jOCtlz4ZEh1qdcnKPzr6K0LDHf/xzAL4tegFYg0CLCSqgmrVcx/BWD8cb6xIJUwgk2/2aC1ZPoyel99bFZh+SvPJv59i4EFfk/BAQZwSKi02BUJim+BjeaLOFPNgvD123cu4K6/4mU44l/0Rsw13XpfKWIg23gMxKDb6+SFy8vxq3JIKbcW32gj/UlrEaY+8Sr/Lb7qtA==","i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776309402; c=relaxed/simple;\n\tbh=UX7ckDv0VlBHbW/LbC9WYb59J3AtFFa+/7fccWGzgeM=;\n\th=In-Reply-To:References:Cc:From:To:Subject:Mime-Version:\n\t Content-Type:Date:Message-Id;\n b=CfqqxuKq0IopAPEuk0DsZ1R7wN7olqlC0rsuDCD/IiwvTzfnDQ1KdsSSvueGmfSRL23BGspoytGXnTh7vu2lWbEWlVgy1pbZve7Pd3ZZ3fVkFdfg4liZl3zWG6lRawDaRRnNcavFJG7CLhKz8fiQNDtdAlCZsyFu6VeM59pBNvo="],"ARC-Authentication-Results":["i=2; gandalf.ozlabs.org;\n dmarc=pass (p=quarantine dis=none) header.from=bytedance.com;\n dkim=pass (2048-bit key;\n unprotected) header.d=bytedance.com header.i=@bytedance.com\n header.a=rsa-sha256 header.s=2212171451 header.b=QyKof4OH; dkim-atps=neutral;\n spf=pass (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=linux-ext4+bounces-15856-patchwork-incoming=ozlabs.org@vger.kernel.org;\n receiver=ozlabs.org) smtp.mailfrom=vger.kernel.org","i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=quarantine dis=none) header.from=bytedance.com;\n spf=pass smtp.mailfrom=bytedance.com;\n dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com\n header.b=QyKof4OH; arc=none smtp.client-ip=209.127.230.112"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n s=2212171451; d=bytedance.com; t=1776309389; h=from:subject:\n mime-version:from:date:message-id:subject:to:cc:reply-to:content-type:\n mime-version:in-reply-to:message-id;\n bh=UX7ckDv0VlBHbW/LbC9WYb59J3AtFFa+/7fccWGzgeM=;\n b=QyKof4OH1SmsMUTa5+jColl1FLCwfjDQKZ855nL/3CjJVHNnn8Rk4l6KyW/JHSxH/Au1C+\n pprY6meYKZgaLU/10sBCPI5yiGoBREy3oBWF6YZtJ+cd9yWyWRb7zOXp8n+Sj9EhQau04H\n YcrqTA7V9H1JbzmylRbX2tmt7eTE9/8e1nERyw7XNZBTeoU82MZKLUrsjBa0+/czeS2iPH\n vh7F+gD7QcGOIeiNzzVgIBOiZLYJrnnsp661SUDKdfzgulT+YgDvNIZqOq7wMgcD9qT9cz\n KNpWSgi3dzC0pYlUgeS/fhXPR90K3qPD7+gvw2k0fvXH3wpEY50hD0vYujPzog==","In-Reply-To":"<ad867C8dlaQGLS97@infradead.org>","References":"<20260414122647.15686-1-changfengnan@bytedance.com>\n\t<ad867C8dlaQGLS97@infradead.org>","Content-Transfer-Encoding":"quoted-printable","Cc":"\"Fengnan Chang\" <fengnanchang@gmail.com>, \"brauner\" <brauner@kernel.org>,\n\t\"djwong\" <djwong@kernel.org>, \"linux-xfs\" <linux-xfs@vger.kernel.org>,\n\t\"linux-fsdevel\" <linux-fsdevel@vger.kernel.org>,\n\t\"linux-ext4\" <linux-ext4@vger.kernel.org>, <lidiangang@bytedance.com>","From":"\"changfengnan\" <changfengnan@bytedance.com>","To":"\"Christoph Hellwig\" <hch@infradead.org>","Subject":"Re: [RFC PATCH] iomap: add fast read path for small direct I/O","Precedence":"bulk","X-Mailing-List":"linux-ext4@vger.kernel.org","List-Id":"<linux-ext4.vger.kernel.org>","List-Subscribe":"<mailto:linux-ext4+subscribe@vger.kernel.org>","List-Unsubscribe":"<mailto:linux-ext4+unsubscribe@vger.kernel.org>","Mime-Version":"1.0","X-Lms-Return-Path":"\n <lba+169e0548b+d36ed1+vger.kernel.org+changfengnan@bytedance.com>","Content-Type":"text/plain; charset=UTF-8","Date":"Thu, 16 Apr 2026 11:16:23 +0800","Message-Id":"\n <d9210bcdf73fbe1ac8b6ec132865609a3ed68688.eee197c0.e67e.40c8.bd15.8fab5bbb42db@bytedance.com>","X-Spam-Status":"No, score=-1.2 required=5.0 tests=ARC_SIGNED,ARC_VALID,\n\tDKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DMARC_PASS,\n\tHEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,\n\tSPF_PASS autolearn=disabled version=4.0.1","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on gandalf.ozlabs.org"}},{"id":3677910,"web_url":"http://patchwork.ozlabs.org/comment/3677910/","msgid":"<d9210bcdf73fbe1ac8b6ec132865609a3ed68688.bd12b07f.c444.4fe0.8460.b6fed4af7332@bytedance.com>","list_archive_url":null,"date":"2026-04-16T03:22:08","subject":"Re: [RFC PATCH] iomap: add fast read path for small direct I/O","submitter":{"id":85004,"url":"http://patchwork.ozlabs.org/api/people/85004/","name":"changfengnan","email":"changfengnan@bytedance.com"},"content":"> From: \"Ojaswin Mujoo\"<ojaswin@linux.ibm.com>\n> Date:  Thu, Apr 16, 2026, 03:07\n> Subject:  Re: [RFC PATCH] iomap: add fast read path for small direct I/O\n> To: \"Fengnan Chang\"<fengnanchang@gmail.com>\n> Cc: <brauner@kernel.org>, <djwong@kernel.org>, <linux-xfs@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>, <linux-ext4@vger.kernel.org>, <lidiangang@bytedance.com>, \"Fengnan Chang\"<changfengnan@bytedance.com>\n> On Tue, Apr 14, 2026 at 08:26:47PM +0800, Fengnan Chang wrote:\n> > When running 4K random read workloads on high-performance Gen5 NVMe\n> > SSDs, the software overhead in the iomap direct I/O path\n> > (__iomap_dio_rw) becomes a significant bottleneck.\n> > \n> > Using io_uring with poll mode for a 4K randread test on a raw block\n> > device:\n> > taskset -c 30 ./t/io_uring -p1 -d512 -b4096 -s32 -c32 -F1 -B1 -R1 -X1\n> > -n1 -P1 /dev/nvme10n1\n> > Result: ~3.2M IOPS\n> > \n> > Running the exact same workload on ext4 and XFS:\n> > taskset -c 30 ./t/io_uring -p1 -d512 -b4096 -s32 -c32 -F1 -B1 -R1 -X1\n> > -n1 -P1 /mnt/testfile\n> > Result: ~1.9M IOPS\n> \n> Hi Fengnan, interesting optimization! \n> Which test suite are you using here for the io_uring tests? \nThis is test 4k randread with QD 512 in io_uring poll mode. \nIf you use fio, almost like this, but ./t/io_uring  can get higher IOPS.\nfio \\\n  --name=io_uring_test \\\n  --ioengine=io_uring \\\n  --filename=/mnt/testfile \\\n  --direct=1 \\\n  --rw=randread \\\n  --bs=4096 \\\n  --iodepth=512 \\\n  --iodepth_batch_submit=32 \\\n  --iodepth_batch_complete_min=32 \\\n  --hipri=1 \\\n  --fixedbufs=1 \\\n  --registerfiles=1 \\\n  --nonvectored=1 \\\n  --sqthread_poll=1\n\n> > \n> > Profiling the ext4 workload reveals that a significant portion of CPU\n> > time is spent on memory allocation and the iomap state machine\n> > iteration:\n> >   5.33%  [kernel]  [k] __iomap_dio_rw\n> >   3.26%  [kernel]  [k] iomap_iter\n> >   2.37%  [kernel]  [k] iomap_dio_bio_iter\n> >   2.35%  [kernel]  [k] kfree\n> >   1.33%  [kernel]  [k] iomap_dio_complete\n> \n> Hmm read is usually under a shared lock for inode as well as extent\n> lookup so we should ideally not be blocking too much there. Can you\n> share a bit more detailed perf report. I'd be interested to see where\n> in iomap_iter() are you seeing the regression?\nAre there enough images of the flame diagram? I’ve attached them.\next4_poll_7.svg is without this patch, iomap_fast.svg is with this patch.\n\n> > \n> > I attempted several incremental optimizations in the __iomap_dio_rw()\n> > path to close the gap:\n> > 1. Allocating the `bio` and `struct iomap_dio` together to avoid a\n> >    separate kmalloc. However, because `struct iomap_dio` is relatively\n> >    large and the main path is complex, this yielded almost no\n> >    performance improvement.\n> > 2. Reducing unnecessary state resets in the iomap state machine (e.g.,\n> >    skipping `iomap_iter_reset_iomap` where safe). This provided a ~5%\n> >    IOPS boost, which is helpful but still falls far short of closing\n> >    the gap with the raw block device.\n> > \n> \n> <...>\n> \n> >  \n> > +static bool iomap_dio_fast_read_enabled = true;\n> > +\n> > +struct iomap_dio_fast_read {\n> > +        struct kiocb        *iocb;\n> > +        size_t                size;\n> > +        bool                should_dirty;\n> > +        struct work_struct        work;\n> > +        struct bio        bio ____cacheline_aligned_in_smp;\n> \n> As Christoph pointed out, were you seeing any performance loss due to\n> not aligning to cacheline? Architectures like powerpc have a 128byte\n> cacheline and we could end up wasting significant space here.\nGet your point. I'll check.\n\n> \n> > +};\n> > +\n> > +static struct bio_set iomap_dio_fast_read_pool;\n> > +\n> > +static void iomap_dio_fast_read_complete_work(struct work_struct *work)\n> > +{\n> \n> <...>\n> \n> > +\n> > +static inline bool iomap_dio_fast_read_supported(struct kiocb *iocb,\n> > +                                          struct iov_iter *iter,\n> > +                                          unsigned int dio_flags,\n> > +                                          size_t done_before)\n> > +{\n> > +        struct inode *inode = file_inode(iocb->ki_filp);\n> > +        size_t count = iov_iter_count(iter);\n> > +        unsigned int alignment;\n> > +\n> > +        if (!iomap_dio_fast_read_enabled)\n> > +                return false;\n> > +        if (iov_iter_rw(iter) != READ)\n> > +                return false;\n> > +\n> > +        /*\n> > +         * Fast read is an optimization for small IO. Filter out large IO early\n> > +         * as it's the most common case to fail for typical direct IO workloads.\n> > +         */\n> > +        if (count > inode->i_sb->s_blocksize)\n> > +                return false;\n> > +\n> > +        if (is_sync_kiocb(iocb) || done_before)\n> \n> Did you try this for sync reads as well? I think we should be seeing\n> similar benefits with sync reads too. Further, if the fast path helps us\n> reduce the critical section under inode lock, it could be a good win for\n> mixed read write workloads.\nGet. sync read will support in next version.\n> \n> > +                return false;\n> > +        if (dio_flags & (IOMAP_DIO_FORCE_WAIT | IOMAP_DIO_BOUNCE))\n> > +                return false;\n> > +        if (iocb->ki_pos + count > i_size_read(inode))\n> > +                return false;\n> > +        if (IS_ENCRYPTED(inode) || fsverity_active(inode))\n> > +                return false;\n> > +\n> > +        if (count < bdev_logical_block_size(inode->i_sb->s_bdev))\n> > +                return false;\n> > +\n> > +        if (dio_flags & IOMAP_DIO_FSBLOCK_ALIGNED)\n> > +                alignment = i_blocksize(inode);\n> > +        else\n> > +                alignment = bdev_logical_block_size(inode->i_sb->s_bdev);\n> > +\n> > +        if ((iocb->ki_pos | count) & (alignment - 1))\n> > +                return false;\n> > +\n> > +        return true;\n> > +}\n> > +\n> > +static ssize_t iomap_dio_fast_read_async(struct kiocb *iocb,\n> \n> <...>\n> \n> > +static ssize_t fast_read_enable_store(struct kobject *kobj,\n> > +                                      struct kobj_attribute *attr,\n> > +                                      const char *buf, size_t count)\n> > +{\n> > +        bool enable;\n> > +        int ret;\n> > +\n> > +        ret = kstrtobool(buf, &enable);\n> > +        if (ret)\n> > +                return ret;\n> > +\n> > +        iomap_dio_fast_read_enabled = enable;\n> > +        return count;\n> > +}\n> > +\n> > +static struct kobj_attribute fast_read_enable_attr =\n> > +        __ATTR(fast_read_enable, 0644, fast_read_enable_show, fast_read_enable_store);\n> > +\n> > +static struct kobject *iomap_kobj;\n> > +\n> > +static int __init iomap_dio_sysfs_init(void)\n> \n> Since we do more than sysfs work here, maybe we can have a more generic\n> name like iomap_dio_init(void) or iomap_dio_fast/simple_read_init().\nSounds good.\n\n> \n> \n> > +{\n> > +        int ret;\n> > +\n> > +        ret = bioset_init(&iomap_dio_fast_read_pool, 4,\n> > +                          offsetof(struct iomap_dio_fast_read, bio),\n> > +                          BIOSET_NEED_BVECS | BIOSET_PERCPU_CACHE);\n> > +        if (ret)\n> > +                return ret;\n> > +\n> > +        iomap_kobj = kobject_create_and_add(\"iomap\", fs_kobj);\n> > +        if (!iomap_kobj) {\n> > +                bioset_exit(&iomap_dio_fast_read_pool);\n> > +                return -ENOMEM;\n> > +        }\n> > +\n> > +        if (sysfs_create_file(iomap_kobj, &fast_read_enable_attr.attr)) {\n> > +                kobject_put(iomap_kobj);\n> > +                bioset_exit(&iomap_dio_fast_read_pool);\n> > +                return -ENOMEM;\n> > +        }\n> > +\n> > +        return 0;\n> > +}\n> > +fs_initcall(iomap_dio_sysfs_init);\n> > -- \n> \n> Regards,\n> ojaswin\n> \n> > 2.39.5 (Apple Git-154)\n> >\n>","headers":{"Return-Path":"\n <SRS0=pTsz=CP=vger.kernel.org=linux-ext4+bounces-15857-patchwork-incoming=ozlabs.org@ozlabs.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linux-ext4@vger.kernel.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","patchwork-incoming@ozlabs.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=bytedance.com header.i=@bytedance.com\n header.a=rsa-sha256 header.s=2212171451 header.b=j/CFw5PQ;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=ozlabs.org\n (client-ip=2404:9400:2221:ea00::3; helo=mail.ozlabs.org;\n envelope-from=srs0=ptsz=cp=vger.kernel.org=linux-ext4+bounces-15857-patchwork-incoming=ozlabs.org@ozlabs.org;\n receiver=patchwork.ozlabs.org)","gandalf.ozlabs.org;\n arc=pass smtp.remote-ip=172.234.253.10 arc.chain=subspace.kernel.org","gandalf.ozlabs.org;\n dmarc=pass (p=quarantine dis=none) header.from=bytedance.com","gandalf.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=bytedance.com header.i=@bytedance.com\n header.a=rsa-sha256 header.s=2212171451 header.b=j/CFw5PQ;\n\tdkim-atps=neutral","gandalf.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=linux-ext4+bounces-15857-patchwork-incoming=ozlabs.org@vger.kernel.org;\n receiver=ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com\n header.b=\"j/CFw5PQ\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=209.127.230.113","smtp.subspace.kernel.org;\n dmarc=pass (p=quarantine dis=none) header.from=bytedance.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=bytedance.com"],"Received":["from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fx3H75QTHz1yDF\n\tfor <incoming@patchwork.ozlabs.org>; Thu, 16 Apr 2026 13:22:43 +1000 (AEST)","from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3])\n\tby gandalf.ozlabs.org (Postfix) with ESMTP id 4fx3H74Krfz4wTD\n\tfor <incoming@patchwork.ozlabs.org>; Thu, 16 Apr 2026 13:22:43 +1000 (AEST)","by gandalf.ozlabs.org (Postfix)\n\tid 4fx3H73lWgz4wTW; Thu, 16 Apr 2026 13:22:43 +1000 (AEST)","from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby gandalf.ozlabs.org (Postfix) with ESMTPS id 4fx3H26s8bz4wTD\n\tfor <patchwork-incoming@ozlabs.org>; Thu, 16 Apr 2026 13:22:38 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 6BE2A30A6901\n\tfor <patchwork-incoming@ozlabs.org>; Thu, 16 Apr 2026 03:22:27 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 87ED3285CA2;\n\tThu, 16 Apr 2026 03:22:25 +0000 (UTC)","from va-1-113.ptr.blmpb.com (va-1-113.ptr.blmpb.com\n [209.127.230.113])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 4986D175A85\n\tfor <linux-ext4@vger.kernel.org>; Thu, 16 Apr 2026 03:22:23 +0000 (UTC)"],"ARC-Seal":["i=2; a=rsa-sha256; d=ozlabs.org; s=201707; t=1776309763; cv=pass;\n\tb=PwUYuz4rO42OM+W5Qt0gbHwU8k0wSTJ4LAzwkYYHsAp0QA4K+Mh7vc2fqUSn90WaYLI7gOZtYfZSGt4kvv2+zYMrCMo4v8ethFerkaEaBASPwWQs8jdFOBJm8svJimXCK3IXvLwyxduL3F0sLl9Q6Oexe+FWfmJEGKTYOaxrjXHL2mEZyjaTrmHUVP8Xc8lfMttbKFpF8qiomg9y0xA4DXFqQ4ZuVrvwJ0E1rta/mw+7AIzpvQJ9jjsUSKZxTFj2RLdKK8RyZMWy2zBT74PeUy6mofo+EI1qeqM6V19MAlv2Tc91pRlwnrZm6fuIrigKRxF0JvQIgrPhDIU74S9n6w==","i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776309745; cv=none;\n b=Mwh6glJ4I7pDNc6bC08qqXNXmnwPcaO8r2btpj/IOfxgTDSqTlhRnhuihMY5ouF4eWQnAK5mDYsauK1QmeKUN9nK+PhumjzDSC14Jdi4g2D6WVInEGkCi42ncujNpBKrdNKvCmdYMT63a0CIeFJw10eCHUJ0v8fo/vekoZhuPK4="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=ozlabs.org; s=201707;\n\tt=1776309763; c=relaxed/relaxed;\n\tbh=gyPoKu/kLu1RzhLVcg/WK8o2NdYonYfQbzMZNAW+5Bk=;\n\th=Date:Message-Id:Subject:References:Content-Type:To:Cc:From:\n\t Mime-Version:In-Reply-To;\n b=JYHwbAP/vNQICdiqrFe/myCB+bFJYkYxrKN4ySCBkD1dQ6pzEUdU6sGEpMFwljPz6m/qt43waq51WmywHKlcAWw+PFeLzPufzO5AWDLoAffBBzr9vTvxh1i0VljBu1WxH8+AjIi9c21dMyhoa3Fohu5PKzzOxRYZYEqpAcGQjD9TRe4AxXndyGpHZQV/jmSBj6kvZPv1gmAJFZG5nPh5XpiFAMYQl9xykT23nE3ajnYb8msYrSiGK4Vk8u7e0g8cQkIvVrVO5pi6xDJQJYmc91OBybJGO0V3RlowQBZ7yzon24WXCj+yX+TSREf35PbYKDyEj2W2Smk4zy5+CR0qrg==","i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776309745; c=relaxed/simple;\n\tbh=gyPoKu/kLu1RzhLVcg/WK8o2NdYonYfQbzMZNAW+5Bk=;\n\th=Date:Message-Id:Subject:References:Content-Type:To:Cc:From:\n\t Mime-Version:In-Reply-To;\n b=Kbn3uFPuH6dsJmdMhcycWPiBlmQTo12D40iv3Ello8+az966mZR79IMLn2753xBGlnJBtu5Mr19Vd0VT8F86L0hviG/C1n48dCkht/zGwTVZUK9Cb8D5zNouiNxPQQLVv52IByoHjyxtyfQkr0sO7ZI6Ex0KNPu/TEipoXLwZHc="],"ARC-Authentication-Results":["i=2; gandalf.ozlabs.org;\n dmarc=pass (p=quarantine dis=none) header.from=bytedance.com;\n dkim=pass (2048-bit key;\n unprotected) header.d=bytedance.com header.i=@bytedance.com\n header.a=rsa-sha256 header.s=2212171451 header.b=j/CFw5PQ; dkim-atps=neutral;\n spf=pass (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=linux-ext4+bounces-15857-patchwork-incoming=ozlabs.org@vger.kernel.org;\n receiver=ozlabs.org) smtp.mailfrom=vger.kernel.org","i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=quarantine dis=none) header.from=bytedance.com;\n spf=pass smtp.mailfrom=bytedance.com;\n dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com\n header.b=j/CFw5PQ; arc=none smtp.client-ip=209.127.230.113"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n s=2212171451; d=bytedance.com; t=1776309733; h=from:subject:\n mime-version:from:date:message-id:subject:to:cc:reply-to:content-type:\n mime-version:in-reply-to:message-id;\n bh=gyPoKu/kLu1RzhLVcg/WK8o2NdYonYfQbzMZNAW+5Bk=;\n b=j/CFw5PQ4NvW36lAio/JPPb5TW3jaFx/CGLvtHZPUJ3hDkndRFq19wNx613UzZ7HqWEg8l\n zUQ4yl6f8HP5BcYoCMX3WUAWTTT/l7VLiMRAj4KRqA5PQKTi5Q/mBoVynwVEcQeph3VoFc\n Dt8y+PCohkdlqQMOpWR9syFvc8mE7FC0sPlaRh25WNe/QHPQvqmbnlS4dL80ZljChG4WWO\n MlCDY7SPs1Z3/jgkA91z+99QQEzgaVZAAkYzm9UWFBOi4Kny7rCM+UXcfR9aV07Jcc3WTP\n 467lay2Q/+ZOppBZyDJg6jX5PRDX1caknVSep1rdfadxVgcAunH1ckpJChPIfQ==","Date":"Thu, 16 Apr 2026 11:22:08 +0800","Message-Id":"\n <d9210bcdf73fbe1ac8b6ec132865609a3ed68688.bd12b07f.c444.4fe0.8460.b6fed4af7332@bytedance.com>","Subject":"Re: [RFC PATCH] iomap: add fast read path for small direct I/O","X-Lms-Return-Path":"\n <lba+169e055e3+c801dc+vger.kernel.org+changfengnan@bytedance.com>","References":"<20260414122647.15686-1-changfengnan@bytedance.com>\n\t<ad_h0JMX2Jo-QODG@li-dc0c254c-257c-11b2-a85c-98b6c1322444.ibm.com>","Content-Type":"multipart/mixed;\n boundary=89c4366213057dd643c55111944edb2063d3db12f312f6c98fed13262704","To":"\"Ojaswin Mujoo\" <ojaswin@linux.ibm.com>","Cc":"\"Fengnan Chang\" <fengnanchang@gmail.com>, <brauner@kernel.org>,\n\t<djwong@kernel.org>, <linux-xfs@vger.kernel.org>,\n\t<linux-fsdevel@vger.kernel.org>, <linux-ext4@vger.kernel.org>,\n\t<lidiangang@bytedance.com>","From":"\"changfengnan\" <changfengnan@bytedance.com>","Precedence":"bulk","X-Mailing-List":"linux-ext4@vger.kernel.org","List-Id":"<linux-ext4.vger.kernel.org>","List-Subscribe":"<mailto:linux-ext4+subscribe@vger.kernel.org>","List-Unsubscribe":"<mailto:linux-ext4+unsubscribe@vger.kernel.org>","Mime-Version":"1.0","In-Reply-To":"\n <ad_h0JMX2Jo-QODG@li-dc0c254c-257c-11b2-a85c-98b6c1322444.ibm.com>","X-Spam-Status":"No, score=-1.2 required=5.0 tests=ARC_SIGNED,ARC_VALID,\n\tDKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DMARC_PASS,\n\tHEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,\n\tSPF_PASS autolearn=disabled version=4.0.1","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on gandalf.ozlabs.org"}},{"id":3678528,"web_url":"http://patchwork.ozlabs.org/comment/3678528/","msgid":"<aeHhrsGtJRhP521d@infradead.org>","list_archive_url":null,"date":"2026-04-17T07:30:54","subject":"Re: [RFC PATCH] iomap: add fast read path for small direct I/O","submitter":{"id":178,"url":"http://patchwork.ozlabs.org/api/people/178/","name":"Christoph Hellwig","email":"hch@infradead.org"},"content":"On Thu, Apr 16, 2026 at 11:16:23AM +0800, changfengnan wrote:\n> > But it already is a major improvement, and one that would apply outside\n> > of narrow special cases.  So I'd really like to see that patch.\n> You can see this in:\n> https://lore.kernel.org/linux-fsdevel/20260416030642.26744-1-changfengnan@bytedance.com/T/#u\n\nThanks!\n\n> > All direct I/O requires this.\n> > \n> > > - No bounce buffering, fscrypt, or fsverity involved.\n> > > - No custom `iomap_dio_ops` (dops) registered by the filesystem.\n> > \n> > I'm really curious at what difference this makes.  It removes a few\n> > branches, but should not have much of an effect while limiting the\n> > applicability a lot.\n> Yes, the impact shouldn’t be significant. \n> Since this is just a RFC version to confirm that I’m on the right path, there\n> are many aspects that haven’t been fully thought through yet. I haven’t\n> tested these scenarios yet, but I’ll add support for them later to\n> check  exactly what the impact is.\n\nSure.  It might also make sense to skip some of this if it brings a big\nenough benefit.\n\n> > > +struct iomap_dio_fast_read {\n> > > +        struct kiocb        *iocb;\n> > > +        size_t                size;\n> > > +        bool                should_dirty;\n> > > +        struct work_struct        work;\n> > > +        struct bio        bio ____cacheline_aligned_in_smp;\n> > \n> > Does the cache line alignment matter here?  If yes, can you explain why\n> > in a comment?\n> \n> I copy this from struct blkdev_dio , I'll do some test to verfiy. \n\nThanks.  Btw, another thing that might be worth is to drop the\nwork_struct and reuse iomap_fail_reads or something similar to it.\nThis would be a pretty big size reduction.  Additionally we should\nbe able to kill should_dirty and just rely on bio or kiocb flags.","headers":{"Return-Path":"\n <SRS0=+kTR=CQ=vger.kernel.org=linux-ext4+bounces-15882-patchwork-incoming=ozlabs.org@ozlabs.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linux-ext4@vger.kernel.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","patchwork-incoming@ozlabs.org"],"Authentication-Results":["legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=ozlabs.org\n (client-ip=2404:9400:2221:ea00::3; helo=mail.ozlabs.org;\n envelope-from=srs0=+ktr=cq=vger.kernel.org=linux-ext4+bounces-15882-patchwork-incoming=ozlabs.org@ozlabs.org;\n receiver=patchwork.ozlabs.org)","gandalf.ozlabs.org;\n arc=pass smtp.remote-ip=\"2600:3c04:e001:36c::12fc:5321\"\n arc.chain=subspace.kernel.org","gandalf.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=infradead.org","gandalf.ozlabs.org;\n\tdkim=pass (2048-bit key;\n secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256\n header.s=bombadil.20210309 header.b=sh0191ye;\n\tdkim-atps=neutral","gandalf.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c04:e001:36c::12fc:5321; helo=tor.lore.kernel.org;\n envelope-from=linux-ext4+bounces-15882-patchwork-incoming=ozlabs.org@vger.kernel.org;\n receiver=ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org\n header.b=\"sh0191ye\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=198.137.202.133","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=infradead.org","smtp.subspace.kernel.org;\n spf=none smtp.mailfrom=bombadil.srs.infradead.org"],"Received":["from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1 raw public key)\n server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fxmlZ4sPBz1yD3\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 17 Apr 2026 17:31:22 +1000 (AEST)","from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3])\n\tby gandalf.ozlabs.org (Postfix) with ESMTP id 4fxmlZ2NySz4wKT\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 17 Apr 2026 17:31:22 +1000 (AEST)","by gandalf.ozlabs.org (Postfix)\n\tid 4fxmlZ2H3Lz4wM8; Fri, 17 Apr 2026 17:31:22 +1000 (AEST)","from tor.lore.kernel.org (tor.lore.kernel.org\n [IPv6:2600:3c04:e001:36c::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest\n SHA256)\n\t(No client certificate requested)\n\tby gandalf.ozlabs.org (Postfix) with ESMTPS id 4fxmlP2lTMz4wKT\n\tfor <patchwork-incoming@ozlabs.org>; Fri, 17 Apr 2026 17:31:13 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id 67467304D176\n\tfor <patchwork-incoming@ozlabs.org>; Fri, 17 Apr 2026 07:31:03 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id DFD5E34D911;\n\tFri, 17 Apr 2026 07:30:58 +0000 (UTC)","from bombadil.infradead.org (bombadil.infradead.org\n [198.137.202.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 13D381C6FF5;\n\tFri, 17 Apr 2026 07:30:54 +0000 (UTC)","from hch by bombadil.infradead.org with local (Exim 4.98.2 #2 (Red\n Hat Linux))\n\tid 1wDdfC-00000003aW0-0FEU;\n\tFri, 17 Apr 2026 07:30:54 +0000"],"ARC-Seal":["i=2; a=rsa-sha256; d=ozlabs.org; s=201707; t=1776411082; cv=pass;\n\tb=LUO12bAZAK4QM4XAmgx5KOkhH7VC2bbAXfbkUMOdvD/BDJoQ20R1/J2C0RKEYEDidS1L+XZbcl616qjl1geCCuInUW1FGZkfAD+9EnpMJRkuarTSbotL6ZrpgcAlY2xUB8oQaw+5JjUeRpEwXguClrARBmQKY/GpUNmTySjPrmhAwqD4LJX/piEUe6Pm9DW557P85d0okuUbFfUw1e2MlSF2yqFR9X+2qA8VTDFjECY49rOc7WHP2frbpjXpLuK3e+wjoFnNMaEZuyw7DwNAR1BkXIl02SSzGxnFcOg3O2VRTImMKwWcQN1sxXHFCHzDjQ52bZSEIXviykREqFoBCg==","i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776411058; cv=none;\n b=PBxgZTikpoXlFJQ0R0cH+KXK9hgncID8VcEI8oynaZvI7OwAFUzSRDw7eYM+8iwG3mGaqpjWHfkqhDHfT6zYSKGNApP+DTZfR56mT5DsbAhoMZFia9wa1l8TmzH3SmOvnG6KTq1mgveBZFnMkFmR0tjyMMuirTO96ctFSizfjgQ="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=ozlabs.org; s=201707;\n\tt=1776411082; c=relaxed/relaxed;\n\tbh=/l71e/ER/+VQEChh8Dmezn6S3hUrL+BwD90ojgmYkI0=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=X/AZRdRfYqbNAMHHKn9OS6PxaBl+sMiVYlxxLUP2G8NYBFP+vxUIkacoV/e5beNXdcsOJtj33Tf3HC9zo95zc01T65QPXDD0O6/ojJkKnTYAnSrbt0uEoNCnYLmU3YHWXr8aPtRaPTWSe1c5hTraPbfYT+Dotbf+Nic8zi61auZ/kCWt7jCjsvu5Y/r4k5EuRL0bWLBxp5fxcW+rAqH7olHTWSxE8oGghlWNgd+YU7lwNboVR6mo3mVeeD9dbSfFPSzOPqmhPUtajciNe2CVQ5C22QSdTgcBUSmFp7ETuyte4hfT9EKjhljorLaa3IkTHQQdiZCepSXoywkSaOnjMw==","i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776411058; c=relaxed/simple;\n\tbh=aodTMjFDDLH0XqR5x0JMN+7jrIXJsaPFvb1NeWpriGc=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=gjvhz51SnZYIOFwO1nXQb6VtTNiMgqcZMCFOOysfmDjgSrQw/TkGq9KNrzhdHXPmDkb/Pj911nQINaGlTCg0I9vnFlEolDz6VkeQ18sDFXVbW6olLgZs8PVR32EVnMlX8pCKBpwExdMZN1qVLL52jInP4RqxWO8zaV4N85ardms="],"ARC-Authentication-Results":["i=2; gandalf.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=infradead.org;\n dkim=pass (2048-bit key;\n secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256\n header.s=bombadil.20210309 header.b=sh0191ye; dkim-atps=neutral;\n spf=pass (client-ip=2600:3c04:e001:36c::12fc:5321; helo=tor.lore.kernel.org;\n envelope-from=linux-ext4+bounces-15882-patchwork-incoming=ozlabs.org@vger.kernel.org;\n receiver=ozlabs.org) smtp.mailfrom=vger.kernel.org","i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=infradead.org;\n spf=none smtp.mailfrom=bombadil.srs.infradead.org;\n dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org\n header.b=sh0191ye; arc=none smtp.client-ip=198.137.202.133"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Transfer-Encoding\n\t:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:\n\tSender:Reply-To:Content-ID:Content-Description;\n\tbh=/l71e/ER/+VQEChh8Dmezn6S3hUrL+BwD90ojgmYkI0=; b=sh0191yeR65OL4SdSNMFvWgXMd\n\tvxwiL06OE7gqXpS8Cdb6nXvra9TNaXTFQvPSJ0fpa7juw73mRzf422X1RMlSJP17H+BZBqWPm9BGL\n\thil2T9cCAkmDoAWqVzlTOVu8fxKGBJ9OQM1ifn64JQmgAweB44W85oZ6UZcOKu57djS6qwq8blyPP\n\tVEG77Js1CqxzaKHNud6Aio21CNFC5xSsBm2CxuqnYxSf8Rejsr5A5PthV5Vx2KmeGFs5jfTxPm4pH\n\tpyewxrnN0n6N9YqxFxYa4k3TRFsg36qaFsIZHdonXcfQNc9sAsk7f8Y5ZsmWp1qIRVbkCYbZmDQpJ\n\tpogLEkZg==;","Date":"Fri, 17 Apr 2026 00:30:54 -0700","From":"Christoph Hellwig <hch@infradead.org>","To":"changfengnan <changfengnan@bytedance.com>","Cc":"Christoph Hellwig <hch@infradead.org>,\n\tFengnan Chang <fengnanchang@gmail.com>,\n\tbrauner <brauner@kernel.org>, djwong <djwong@kernel.org>,\n\tlinux-xfs <linux-xfs@vger.kernel.org>,\n\tlinux-fsdevel <linux-fsdevel@vger.kernel.org>,\n\tlinux-ext4 <linux-ext4@vger.kernel.org>, lidiangang@bytedance.com","Subject":"Re: [RFC PATCH] iomap: add fast read path for small direct I/O","Message-ID":"<aeHhrsGtJRhP521d@infradead.org>","References":"<20260414122647.15686-1-changfengnan@bytedance.com>\n <ad867C8dlaQGLS97@infradead.org>\n <d9210bcdf73fbe1ac8b6ec132865609a3ed68688.eee197c0.e67e.40c8.bd15.8fab5bbb42db@bytedance.com>","Precedence":"bulk","X-Mailing-List":"linux-ext4@vger.kernel.org","List-Id":"<linux-ext4.vger.kernel.org>","List-Subscribe":"<mailto:linux-ext4+subscribe@vger.kernel.org>","List-Unsubscribe":"<mailto:linux-ext4+unsubscribe@vger.kernel.org>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"\n <d9210bcdf73fbe1ac8b6ec132865609a3ed68688.eee197c0.e67e.40c8.bd15.8fab5bbb42db@bytedance.com>","X-SRS-Rewrite":"SMTP reverse-path rewritten from <hch@infradead.org> by\n bombadil.infradead.org. See http://www.infradead.org/rpr.html","X-Spam-Status":"No, score=-1.2 required=5.0 tests=ARC_SIGNED,ARC_VALID,\n\tDKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DMARC_PASS,\n\tHEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,\n\tSPF_PASS autolearn=disabled version=4.0.1","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on gandalf.ozlabs.org"}}]