On 01/09/17 15:58, Ulf Hansson wrote: > + 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. That doesn't make sense. This patch set is not converting the legacy driver to mq therefore it cannot overlook anything for converting to mq. > > 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. Lose what benefits? > 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. Unlike HDDs, eMMC must switch between internal partitions (LUNs) so there must a way to arbitrate between them. > Of course, if Linus/Christoph don't think this intermediate approach > is good enough, we will have to respect that as well. -- 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
