can we drop the bio based path in null_blk

can we drop the bio based path in null_blk

[Christoph Hellwig]

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?

Re: can we drop the bio based path in null_blk

[Hannes Reinecke]

On 1/23/24 09:49, 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?
> 
All for it.
But I guess that means we should convert zram...

Cheers,

Hannes

Re: can we drop the bio based path in null_blk

[Pankaj Raghav (Samsung)]

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?

[1] https://lore.kernel.org/linux-block/db1d7cd7-6c89-7d6b-3fe5-3778bb3cb5e9@kernel.dk/

-- 
Pankaj Raghav

Re: can we drop the bio based path in null_blk

[Jens Axboe]

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

Re: can we drop the bio based path in null_blk

[Christoph Hellwig]

On Wed, Jan 24, 2024 at 09:31:25PM +0100, Pankaj Raghav (Samsung) wrote:
> 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.

Well, it's two different things.  My prime concern right now is
null_blk, which is very clumsy due to the two different I/O paths,
and actually broken in that the bio mode doesn't respect various
I/O limits that can be configured, and at least in zone modes also
ones that aren't configured but required (I/Os spanning zones).

Re: can we drop the bio based path in null_blk

[Chaitanya Kulkarni]

Christoph,

On 1/25/24 00:15, Christoph Hellwig wrote:
> On Wed, Jan 24, 2024 at 09:31:25PM +0100, Pankaj Raghav (Samsung) wrote:
>> 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.
> Well, it's two different things.  My prime concern right now is
> null_blk, which is very clumsy due to the two different I/O paths,
> and actually broken in that the bio mode doesn't respect various
> I/O limits that can be configured, and at least in zone modes also
> ones that aren't configured but required (I/Os spanning zones).
>
>

Focusing on null_blk :-

removing bio mode will significantly simplify null_blk code, but then which
bio based driver we should use as a replacement to :-

1. Establish baseline stability of block layer bio mode ? fio verify 
test etc..
2. Establish performance consistency of block layer bio mode driver across
    different kernel release?
3. Which driver one should use to compare the bio vs mq mode performance
    comparison without the need of real H/W ?

one candidate comes to mind is brd for #1 & #2, but unfortunately it doesn't
support blk-mq mode so #3 is still an open question or we don't have to 
worry
about #3 at all ?

-ck

Re: can we drop the bio based path in null_blk

[Pankaj Raghav]

On 25/01/2024 09:15, Christoph Hellwig wrote:
> On Wed, Jan 24, 2024 at 09:31:25PM +0100, Pankaj Raghav (Samsung) wrote:
>> 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.
> 
> Well, it's two different things.  My prime concern right now is
> null_blk, which is very clumsy due to the two different I/O paths,
> and actually broken in that the bio mode doesn't respect various
> I/O limits that can be configured, and at least in zone modes also
> ones that aren't configured but required (I/Os spanning zones).
> 

My 2 cents: The drivers that still use submit_bio are mostly memory
based except for n64. And there is only one blktest(block/023) that
tests the bio path (Shinchiro can comment here if this is wrong).

So we could remove the submit_bio path in null_blk to simplify things
as most of the drivers that uses this path do not do anything complicated
in submit_bio and are mostly memory based.

--
Pankaj Raghav