On Fri, Oct 28, 2016 at 11:32:21AM +0200, Linus Walleij wrote: > So I'm not just complaining by the way, I'm trying to fix this. Also > Bartlomiej from Samsung has done some stabs at switching MMC/SD > to blk-mq. I just rebased my latest stab at a naïve switch to blk-mq > to v4.9-rc2 with these results. > > The patch to enable MQ looks like this: > https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-stericsson.git/commit/?h=mmc-mq&id=8f79b527e2e854071d8da019451da68d4753f71d > > I run these tests directly after boot with cold caches. The results > are consistent: I ran the same commands 10 times in a row.
A couple comments from a quick look over the patch: In the changelog you complain: ". Lack of front- and back-end merging in the MQ block layer creating several small requests instead of a few large ones." In blk-mq merging is controller by the BLK_MQ_F_SHOULD_MERGE and BLK_MQ_F_SG_MERGE flags. You set the former, but not the latter. BLK_MQ_F_SG_MERGE controls wether multiple physical contiguous pages get merged into a single segment. For a dd after a fresh boot that is probably very common. Except for the polarity of the merge flags the basic merge functionality between the legacy and blk-mq path should be the same, and if they aren't you've found a bug we need to address. You also say that you disable the pipelining. How much of a performance gain did this feature give when added? How much does just removing that on it's own cost you? While I think that features is rather messy and should be avoided if possible I don't see how it's impossible to implement in blk-mq. If you just increase your queue depth and use the old scheme you should get it - if you currently can't handle the second command for some reason (i.e. the special request magic) you can just return BLK_MQ_RQ_QUEUE_BUSY from the queue_rq function.
