From: Jens Axboe <axboe@kernel.dk>
To: "Pankaj Raghav (Samsung)" <kernel@pankajraghav.com>,
Christoph Hellwig <hch@lst.de>
Cc: linux-block@vger.kernel.org, p.raghav@samsung.com
Subject: Re: can we drop the bio based path in null_blk
Date: Wed, 24 Jan 2024 15:00:42 -0700 [thread overview]
Message-ID: <5d7bbb8a-8542-41c3-b48e-e64b3f5f9170@kernel.dk> (raw)
In-Reply-To: <znc7pqdsqkznoszbzhvxyyphmpqbesjh56ygn5xt5fjej4glvc@mcccy2dky5eg>
On 1/24/24 1:31 PM, Pankaj Raghav (Samsung) wrote:
> On Tue, Jan 23, 2024 at 09:49:42AM +0100, Christoph Hellwig wrote:
>> As we found out recently null_blk never splits bios in bio mode, thus
>> ignoring a lot of it's paramters and having buggy zoned device
>> handling.
>>
>> Is there any good reason to keep this mode around given that all relevant
>> hardware drivers use blk-mq, and the non-so-relevant ones not using
>> blk-mq probably should?
>
> The subject says removing the bio mode in null_blk but here you are
> asking an open question about the non-so-relevant ones should move to
> blk-mq. My input is for the latter part, FWIW.
>
> I tried to convert brd from bio to using blk-mq last year. One of the
> conclusion we reached was that we will see a performance hit when we use
> blk-mq for RAM backed devices because having tag management, etc was
> adding overhead to these drivers[1](You were also part of this
> discussion, so you probably remember it!).
>
> Unless there is a mode in blk-mq that can provide a real fast path for
> these drivers, moving to blk-mq might not be possible?
Yeah, by default, blk-mq will do a bunch of things that you don't need,
like the tag generation. We may be able to have a fops->submit_bio()
hook that just puts a request on the stack with the bio stuffed in
there, and have per-cpu hardware queues to avoid any issues there. I
feel like if we did that, then it should be the same performance. That
won't necessarily solve things like queue quisce etc, however... But
it'd be a start, maybe.
--
Jens Axboe
next prev parent reply other threads:[~2024-01-24 22:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-23 8:49 can we drop the bio based path in null_blk Christoph Hellwig
2024-01-23 9:13 ` Hannes Reinecke
2024-01-24 20:31 ` Pankaj Raghav (Samsung)
2024-01-24 22:00 ` Jens Axboe [this message]
2024-01-25 8:15 ` Christoph Hellwig
2024-01-25 8:57 ` Chaitanya Kulkarni
2024-01-25 9:07 ` Pankaj Raghav
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=5d7bbb8a-8542-41c3-b48e-e64b3f5f9170@kernel.dk \
--to=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=kernel@pankajraghav.com \
--cc=linux-block@vger.kernel.org \
--cc=p.raghav@samsung.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