On 01/09/17 15:58, Ulf Hansson wrote:

+ Christoph

On 1 September 2017 at 13:42, Adrian Hunter [off-list ref] wrote:

quoted

On 31/08/17 14:56, Adrian Hunter wrote:

quoted

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.