Re: Some throughput tests with MQ and BFQ on MMC/SD

[Adrian Hunter <adrian.hunter@intel.com>]

On 20/02/17 15:46, Linus Walleij wrote:
> On Mon, Feb 20, 2017 at 9:03 AM, Adrian Hunter <adrian.hunter@intel.com> wrote:
> 
>> MQ is not better - it is just different.
> 
> Well it is better in the sense that it has active maintainers and is
> not scheduled
> for depreciation.
> 
>> Because mmc devices do not have
>> multiple hardware queues, blk-mq essentially offers nothing but a different
>> way of doing the same thing.
> 
> I think what Ziji is pointing out is the hourglass-shaped structure of MQ.
> It has multiple *issue* queues as well, not just multiple *hardware*
> queues. That means that processes can have issue queues on different
> CPUs and not all requests end up in a single nexus like with the old blk
> layer.

blk-mq has a lighter touch, but if you use BLK_MQ_F_BLOCKING and only have
one hardware context, then you are still putting everything through a single
work item.

> 
> Whether it benefits MMC/SD in the end is a good question. It might,
> testing on multicores with multiple issue threads is needed.
> 
>> It would be better if blk-mq support was experimental until we can see how
>> well it works in practice.
> 
> Do you mean experimental in the MMC/SD stack, such that we should
> merge it as an additional scheduler instead of as the only scheduler
> replacement?

Not sure what you mean by "scheduler".

> 
> I think SCSI did/still does things like that.

A quick look at SCSI shows a module parameter use_blk_mq that defaults based
on a config option CONFIG_SCSI_MQ_DEFAULT i.e. defaults to false unless
selected.

Yes, something like that.

>                                               On the other hand, UBI
> just replaced the old block layer with MQ in commit
> ff1f48ee3bb3, and it is also very widely
> used, so there are example of both approaches. (How typical.)

UBI block is read-only and does not benefit from an I/O scheduler, and has
nothing like a command queue.   It doesn't seem unreasonable that very
different kinds of devices would take different approaches.

Unfortunately, ff1f48ee3bb3 mixes together switching the underlying I/O to
using a scatter gather list and removing a serializing mutex, so it is hard
to tell if improvements came from that or from blk-mq.