On Wed, Feb 22, 2023 at 03:47:43PM -0700, Jens Axboe wrote:

On 2/22/23 3:42?PM, Luis Chamberlain wrote:

quoted

On Tue, Feb 21, 2023 at 04:51:21PM -0700, Jens Axboe wrote:

quoted

On 2/21/23 2:59?PM, Luis Chamberlain wrote:

quoted

On Fri, Feb 17, 2023 at 08:22:15PM +0530, Pankaj Raghav wrote:

quoted

I will park this effort as blk-mq doesn't improve the performance for brd,
and we can retain the submit_bio interface.

I am not sure if the feedback was intended to suggest we shouldn't do
the blk-mq conversion, but rather explain why in some workloads it
may not be as good as the old submit_bio() interface. Probably low
hanging fruit, if we *really* wanted to provide parity for the odd
workloads.

If we *mostly*  we see better performance with blk-mq it would seem
likely reasonable to merge. Dozens of drivers were converted to blk-mq
and *most* without *any* performance justification on them. I think
ming's was the commit log that had the most elaborate performacne
metrics and I think it also showed some *minor* slowdown on some
workloads, but the dramatic gains made it worthwhile.

Most of the conversions to blk-mq didn't even have *any* metrics posted.

You're comparing apples and oranges. I don't want to get into (fairly)
ancient history at this point, but the original implementation was honed
with the nvme conversion - which is the most performant driver/hardware
we have available.

Converting something that doesn't need a scheduler, doesn't need
timeouts, doesn't benefit from merging, doesn't need tagging etc doesn't
make a lot of sense. If you need none of that, *of course* you're going
to see a slowdown from doing all of these extra things by default.
That's pretty obvious.

This isn't about workloads at all.

I'm not arguing mq design over-architecture for simple devices. It is a
given that if one doesn't need some of those things surely they can
create a minor delta loss in performance. I'm asking and suggesting that
despite a few workloads being affected with a *minor delta* for brd for mq
conversion if the huge gains possible on some *other* workloads suffice for
it to be converted over.

We're talking about + ~125% performance boost benefit for randreads.

Please actually read the whole thread. The boost there was due to brd
not supporting nowait, that has since been corrected.

Ah, that's what happens when reading patches over the phone while *on
vacation*, coming back and thinking you *don't* have to re-read the
threads.

And the latest
numbers reflect that and how the expected outcome (bio > blk-mq for brd,
io_uring > aio for both).

Got it thanks!

  Luis