All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: Fengnan Chang <changfengnan@bytedance.com>,
Cc: Matthew Wilcox <willy@infradead.org>,
	"Darrick J. Wong" <djwong@kernel.org>,
	brauner@kernel.org, linux-xfs@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org,
	Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH] iomap: allow iomap using the per-cpu bio cache
Date: Tue, 26 Aug 2025 22:23:05 +0530	[thread overview]
Message-ID: <878qj6qb2m.fsf@gmail.com> (raw)
In-Reply-To: <CAPFOzZvBvHWHUwNLnH+Ss90OMdu91oZsSD0D7_ncjVh0pF29rQ@mail.gmail.com>

Fengnan Chang <changfengnan@bytedance.com> writes:

> Christoph Hellwig <hch@infradead.org> 于2025年8月25日周一 17:21写道:
>>
>> On Mon, Aug 25, 2025 at 04:51:27PM +0800, Fengnan Chang wrote:
>> > No restrictions for now, I think we can enable this by default.
>> > Maybe better solution is modify in bio.c?  Let me do some test first.

If there are other implications to consider, for using per-cpu bio cache
by default, then maybe we can first get the optimizations for iomap in
for at least REQ_ALLOC_CACHE users and later work on to see if this
can be enabled by default for other users too.
Unless someone else thinks otherwise.

Why I am thinking this is - due to limited per-cpu bio cache if everyone
uses it for their bio submission, we may not get the best performance
where needed. So that might require us to come up with a different
approach.

>>
>> Any kind of numbers you see where this makes a different, including
>> the workloads would also be very valuable here.
> I'm test random direct read performance on  io_uring+ext4, and try
> compare to io_uring+ raw blkdev,  io_uring+ext4 is quite poor, I'm try to
> improve this, I found ext4 is quite different with blkdev when run
> bio_alloc_bioset. It's beacuse blkdev ext4  use percpu bio cache, but ext4
> path not. So I make this modify.

I am assuming you meant to say - DIO with iouring+raw_blkdev uses
per-cpu bio cache where as iouring+(ext4/xfs) does not use it.
Hence you added this patch which will enable the use of it - which
should also improve the performance of iouring+(ext4/xfs). 

That make sense to me. 

> My test command is:
> /fio/t/io_uring -p0 -d128 -b4096 -s1 -c1 -F1 -B1 -R1 -X1 -n1 -P1 -t0
> /data01/testfile
> Without this patch:
> BW is 1950MB
> with this patch
> BW is 2001MB.

Ok. That's around 2.6% improvement.. Is that what you were expecting to
see too? Is that because you were testing with -p0 (non-polled I/O)? 

Looking at the numbers here [1] & [2], I was hoping this could give
maybe around 5-6% improvement ;) 

[1]: https://lore.kernel.org/io-uring/cover.1666347703.git.asml.silence@gmail.com/
[2]: https://lore.kernel.org/all/20220806152004.382170-3-axboe@kernel.dk/


-ritesh

  parent reply	other threads:[~2025-08-26 17:25 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-22  8:26 [PATCH] iomap: allow iomap using the per-cpu bio cache Fengnan Chang
2025-08-22 15:05 ` Darrick J. Wong
2025-08-22 15:42   ` Matthew Wilcox
2025-08-22 16:07     ` Ritesh Harjani
2025-08-22 16:51       ` Matthew Wilcox
2025-08-23  4:15         ` Ritesh Harjani
2025-08-25  8:51           ` Fengnan Chang
2025-08-25  9:21             ` Christoph Hellwig
2025-08-25  9:41               ` Fengnan Chang
2025-08-25 10:47                 ` Christoph Hellwig
2025-08-26  9:46                   ` Fengnan Chang
2025-08-26 13:15                     ` Christoph Hellwig
2025-08-26 16:53                 ` Ritesh Harjani [this message]
2025-08-29  4:26                   ` [External] " Fengnan Chang
2025-09-03  8:28                   ` Fengnan Chang
2025-09-06  4:25                     ` Ritesh Harjani
2025-09-03  9:53           ` Pavel Begunkov
     [not found]             ` <CAPFOzZtaKcaSsvUfjiJL2TOwMy-jUkMdboEmp++-USvoUoqjYA@mail.gmail.com>
     [not found]               ` <879fb17c-e6d6-4b1b-bee5-9087ba24a4f2@gmail.com>
2025-09-10 10:52                 ` [External] " Fengnan Chang

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=878qj6qb2m.fsf@gmail.com \
    --to=ritesh.list@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=changfengnan@bytedance.com \
    --cc=djwong@kernel.org \
    --cc=hch@infradead.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=willy@infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.