On 20/02/17 15:46, Linus Walleij wrote: > On Mon, Feb 20, 2017 at 9:03 AM, Adrian Hunter <adrian.hunter@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
