On 2/21/23 2:59?PM, Luis Chamberlain wrote: > On Fri, Feb 17, 2023 at 08:22:15PM +0530, Pankaj Raghav wrote: >> 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. -- Jens Axboe
