+ Christoph On 1 September 2017 at 13:42, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: > On 31/08/17 14:56, Adrian Hunter wrote: >> Here is V7 of the hardware command queue patches without the software >> command queue patches, now using blk-mq. >> >> 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. > > Any comments? A couple of overall comments, for now. To make sure we don't overlook something when converting to mq, I would prefer that we first convert the existing mmc block code to mq, then we add CMDQ on top. Regarding patch1. in the long-term solution, we should really strive towards getting rid of the big mmc host lock, as it causes us to lose some of the benefits on which principles mq is designed upon. However, it may be feasible to use patch1 as an intermediate step, to be able to convert to mq short term. Then we can continue doing the re-factoring, to get rid of the big mmc host lock and solve other relates issues/optimize things. What remains to be seen in this approach, is how well mq performs, as we would still be using the big mmc host lock. We may tolerate some minor regressions, but if too much, there is no other way that first removing the big mmc lock. Of course, if Linus/Christoph don't think this intermediate approach is good enough, we will have to respect that as well. Kind regards Uffe
