Re: [PATCH V7 00/10] mmc: Add Command Queue support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/09/17 12:54, Ulf Hansson wrote:
> On 6 September 2017 at 09:20, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote:
>> On 05/09/17 20:54, Ulf Hansson wrote:
>>> On 5 September 2017 at 10:10, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote:
>>>> On 05/09/17 10:24, Ulf Hansson wrote:
>>>>> [...]
>>>>>
>>>>>>>>
>>>>>>>> I can send blk-mq support for legacy requests in a few days if you like, but
>>>>>>>> I want to hear a better explanation of why you are delaying CQE support.
>>>>>>>
>>>>>>> That would be very nice, however be aware of that we are in the merge
>>>>>>> window, so I am not picking new material for 4.14 from this point. I
>>>>>>> assume you understand why.
>>>>>>
>>>>>> Nope.  This is new functionality - doesn't affect anyone who doesn't have a
>>>>>> command queue engine.  Next to no chance of regressions.  Tested by several
>>>>>> in the community.  Substantially unchanged since February.  It is not even
>>>>>> very much code in the block driver.
>>>>>
>>>>> Let me make it clear, once more - I don't want to maintain more hacks
>>>>> in mmc block layer code.
>>>>>
>>>>> This series add blkmq support, using a method (which may be considered
>>>>> as intermediate) via a new change in patch1 - but only for the new CQE
>>>>> path. That means the old legacy mmc block path is still there. So, for
>>>>> the reason stated above - no thanks!
>>>>
>>>> And where is your alternative.  When I pointed out you need a way to
>>>> arbitrate between internal partitions, you went silent again.
>>>>
>>>> Can't have CQE without blk-mq but can't have blk-mq because you don't
>>>> understand it, is hardly acceptable.
>>>
>>> Adrian, this discussion seems to lead nowhere. Can we please stop and
>>> be constructive instead!
>>
>> If you want to be constructive you will queue CQE support for v4.15 now!
>>
>>>
>>> Regarding the arbitration issue. We have been moving forward,
>>> re-factoring the mmc block driver code, soon also solving the problem
>>> for the rpmb internal partition [1]. Maybe the background to why Linus
>>> is working on mmc block re-factoring, hasn't been entirely clear.
>>> Anyway, it's exactly because of moving closer to address these issues.
>>
>> Nope, wrt blk-mq you are moving sideways with no clear idea where you're going.
>>
>>> Even if the problems certainly becomes a step harder to resolve for
>>> the boot and the general purpose partitions, it's still a path we
>>> should try to find a solution for. Yeah, that may mean we need to
>>> suggest changes for the generic block layer, to teach it to better
>>> deal with these kind of devices.
>>
>> You mean you have no idea how to do it but we are still expected to wait.
>> How is that acceptable!
>>
>>> Finally, I have never said the arbitration issue *must* be solved
>>> before converting to blkmq. Only that we should avoid performance
>>> regressions, but that of course applies to whatever changes we do.
>>
>> Then there is no problem in queuing up the CQE patches now!
> 
> Either you are not paying attention or just being grumpy.
> 
> So for the last time, I don't want to pick CQE, prior the existing mmc
> block code has converted to blkmq.

Which is unreasonable and unacceptable.

> End of discussion!

Hardly.  I plan to submit blk-mq patches in a few days and I expect a proper
response.  Not silence.  Not "consensus".  And especially not "we want to do
it a different way but we don't know what that is".
--
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



[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux