public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: "Fengnan" <changfengnan@bytedance.com>
To: "Dave Chinner" <dgc@kernel.org>
Cc: "Ojaswin Mujoo" <ojaswin@linux.ibm.com>,
	 "Fengnan Chang" <fengnanchang@gmail.com>, <brauner@kernel.org>,
	 <djwong@kernel.org>, <linux-xfs@vger.kernel.org>,
	 <linux-fsdevel@vger.kernel.org>, <linux-ext4@vger.kernel.org>,
	 <lidiangang@bytedance.com>
Subject: Re: [RFC PATCH] iomap: add fast read path for small direct I/O
Date: Wed, 22 Apr 2026 10:43:53 +0800	[thread overview]
Message-ID: <51e30499-88dc-4e0e-8c72-ccc9d06b0f2e@bytedance.com> (raw)
In-Reply-To: <aef79R24wFemmUdN@dread>

[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]

在 2026/4/22 06:36, Dave Chinner 写道:
> On Tue, Apr 21, 2026 at 11:19:31AM +0800, Fengnan wrote:
>> 在 2026/4/21 07:59, Dave Chinner 写道:
>>> I'm clearly missing something here. I'm trying to work out why the
>>> profiles show what they do, but there's differences between them
>>> that do make obvious sense to me.
>>>
>>> It would also be useful to have XFS profiles, because it has a
>>> larger CPU cache footprint than ext4. If what the profiles are
>>> showing is a result of CPU cache residency artifacts, then we'll see
>>> different profile (and, potentially, performance) artifacts with
>>> XFS...
>> The XFS flame graph is also attached now.
>> IOPS: 1.92M->2.3M.
> The callchains in both XFS flame graphs are completely bogus:
>
> <io_uring entry>
> ....
> io_read
> __io_read
> xfs_inode_free_eofblocks
> xfs_prep_free_cowblocks
> iomap_dio_rw
> iomap_dio_simple_read
> xfs_mountfs
> ....
>
> Can you regenerate the profiles, please, and this time check that
> they make sense before posting them?

Sorry, I didn't check xfs before, new flame graph is attached
now, now the callchains make sense.

>
> -Dave.

[-- Attachment #2: xfs_base.svg --]
[-- Type: image/svg+xml, Size: 220396 bytes --]

[-- Attachment #3: xfs_patch.svg --]
[-- Type: image/svg+xml, Size: 201551 bytes --]

      reply	other threads:[~2026-04-22  2:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-14 12:26 [RFC PATCH] iomap: add fast read path for small direct I/O Fengnan Chang
2026-04-15  7:14 ` Christoph Hellwig
2026-04-16  3:16   ` changfengnan
2026-04-17  7:30     ` Christoph Hellwig
2026-04-15 19:06 ` Ojaswin Mujoo
2026-04-16  3:22   ` changfengnan
2026-04-18 19:36     ` Ojaswin Mujoo
2026-04-20 23:59     ` Dave Chinner
2026-04-21  3:19       ` Fengnan
2026-04-21 22:36         ` Dave Chinner
2026-04-22  2:43           ` Fengnan [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51e30499-88dc-4e0e-8c72-ccc9d06b0f2e@bytedance.com \
    --to=changfengnan@bytedance.com \
    --cc=brauner@kernel.org \
    --cc=dgc@kernel.org \
    --cc=djwong@kernel.org \
    --cc=fengnanchang@gmail.com \
    --cc=lidiangang@bytedance.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=ojaswin@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox