From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: "Darrick J. Wong" <djwong@kernel.org>,
Fengnan Chang <changfengnan@bytedance.com>,
brauner@kernel.org, linux-xfs@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org
Subject: Re: [PATCH] iomap: allow iomap using the per-cpu bio cache
Date: Sat, 23 Aug 2025 09:45:58 +0530 [thread overview]
Message-ID: <874ityad1d.fsf@gmail.com> (raw)
In-Reply-To: <aKif_644529sRXhN@casper.infradead.org>
Matthew Wilcox <willy@infradead.org> writes:
> On Fri, Aug 22, 2025 at 09:37:32PM +0530, Ritesh Harjani wrote:
>> Matthew Wilcox <willy@infradead.org> writes:
>> > On Fri, Aug 22, 2025 at 08:05:50AM -0700, Darrick J. Wong wrote:
>> >> Is there a reason /not/ to use the per-cpu bio cache unconditionally?
>> >
>> > AIUI it's not safe because completions might happen on a different CPU
>> > from the submission.
>>
>> At max the bio de-queued from cpu X can be returned to cpu Y cache, this
>> shouldn't be unsafe right? e.g. bio_put_percpu_cache().
>> Not optimal for performance though.
>>
>> Also even for io-uring the IRQ completions (non-polling requests) can
>> get routed to a different cpu then the submitting cpu, correct?
>> Then the completions (bio completion processing) are handled via IPIs on
>> the submtting cpu or based on the cache topology, right?
>>
>> > At least, there's nowhere that sets REQ_ALLOC_CACHE unconditionally.
>> >
>> > This could do with some better documentation ..
>>
>> Agreed. Looking at the history this got added for polling mode first but
>> later got enabled for even irq driven io-uring rw requests [1]. So it
>> make sense to understand if this can be added unconditionally for DIO
>> requests or not.
>
> So why does the flag now exist at all? Why not use the cache
> unconditionally?
I am hoping the author of this patch or folks with io-uring expertise
(which added the per-cpu bio cache in the first place) could answer
this better. i.e.
Now that per-cpu bio cache is being used by io-uring rw requests for
both polled and non-polled I/O. Does that mean, we can kill
IOCB_ALLOC_CACHE check from iomap dio path completely and use per-cpu
bio cache unconditionally by passing REQ_ALLOC_CACHE flag? That means
all DIO requests via iomap can now use this per-cpu bio cache and not
just the one initiated via io-uring path.
Or are there still restrictions in using this per-cpu bio cache, which
limits it to be only used via io-uring path? If yes, what are they? And
can this be documented somewhere?
-ritesh
next prev parent reply other threads:[~2025-08-23 4:35 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 [this message]
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
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=874ityad1d.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=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.