Re: [PATCH V4 00/11] mmc: Add Command Queue support

[Adrian Hunter <adrian.hunter@intel.com>]

On 08/08/17 13:36, Ulf Hansson wrote:
> On 8 August 2017 at 11:26, Adrian Hunter <adrian.hunter@intel.com> wrote:
>> On 07/08/17 16:41, Ulf Hansson wrote:
>>> On 21 July 2017 at 11:49, Adrian Hunter <adrian.hunter@intel.com> wrote:
>>>> Hi
>>>>
>>>> Here is V4 of the hardware command queue patches without the software
>>>> command queue patches.
>>>
>>> Adrian, again apologize for the delay.
>>>
>>> I am reviewing the series now and my intent is to provide comments on
>>> each change separately during the week.
>>>
>>> However, a couple of overall thoughts:
>>>
>>> *) Could you please post some fresh performance measurements, such we
>>> can get some real proof on why CMDQ is worth to be merged? If not
>>> increased throughput, perhaps we can show some decreased I/O requests
>>> latency!?
>>
>> 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.
> 
> Great, that satisfies my request! Could you please fold in this
> information in one of the change-logs, which adds supports for the
> CQE?

Sure

> 
>>
>>>
>>> **) I have spoken to Linus W offlist - and he is still working on the
>>> blkmq port. Although we first need to continue with the
>>> re-factorization of the mmc block/core code, to minimize the bad
>>> impact of our big mmc claim host lock. We should expect a
>>> re-submission of his series quite soonish. However, it's also likely
>>> that we need yet another round of re-factoring, before we can complete
>>> the port to blkmq.
>>>
>>> ***) The reason for bringing up **), is of course because I think
>>> deploying CMDQ support would be better done on top of the blkmq
>>> interface as it's better suited for these kind of device types. My
>>> goal is to reach a better maintenance situation, using more modern mmc
>>> block code. We have spoken about this before, however of course I also
>>> don't want to delay the CMDQ series. Anyway, let's move forward and
>>> see what path we end up taking.
>>
>> There is no advantage to holding up HW CMDQ.
> 
> Maybe not.
> 
> I haven't completed the review yet, but I guess you understand my
> concerns on the impact of the blkmq port.

If the blkmq port were ready there would be no problem.  But I don't think
it should be rushed.  It would be better to throw more light on the issues.

> 
> If I can get some promises about yours support (testing/reviewing/etc)
> of the blkmq port series when going forward, that would of course
> impact my decision on what path to pick.
> 
> Does that sounds reasonable to you?

Sure