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
