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. 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? I think SCSI did/still does things 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.) Yours, Linus Walleij -- 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
