On Tue, Nov 21, 2017 at 2:42 PM, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: > Here is V14 of the hardware command queue patches without the software > command queue patches, now using blk-mq and now with blk-mq support for > non-CQE I/O. > > V14 includes a number of fixes to existing code, changes to default to > blk-mq, and adds patches to remove legacy code. I have looked over the code, I was unable to find a good mergebase to apply it on (I guess it is based on linux-next at some date in the past) so mostly I just looked at it overall, and I can solidly say that this patch series: Acked-by: Linus Walleij <linus.walleij@xxxxxxxxxx> I gave some more explicit review on some initial patches that I think should go in as fixes. I do not expect it to perform any less than the previous iteration on my systems where it was already performing well and Bartlomiej also has confirmed that the patch set works for him. Ulf: I suggest this be applied (+/- some rebasing) early for v4.15. I am positively convinced that we can make things work on top of this. > HW CMDQ offers 25% - 50% better random multi-threaded I/O. I see a slight > 2% drop in sequential read speed but no change to sequential write. Fully acceptable I think. > Non-CQE blk-mq showed a 3% decrease in sequential read performance. This > seemed to be coming from the inferior latency of running work items compared > with a dedicated thread. Hacking blk-mq workqueue to be unbound reduced the > performance degradation from 3% to 1%. Also acceptable I think. > While we should look at changing blk-mq to give better workqueue performance, > a bigger gain is likely to be made by adding a new host API to enable the > next already-prepared request to be issued directly from within ->done() > callback of the current request. I agree. Yours, Linus Walleij
