On 20/02/17 13:04, Ziji Hu wrote:
> Hi Adrian,
>
> On 2017/2/20 16:03, Adrian Hunter wrote:
>> On 17/02/17 15:22, Linus Walleij wrote:
>>> On Fri, Feb 17, 2017 at 12:53 PM, Ziji Hu <[email protected]> wrote:
> <snip>
>>> Ulf describes it: we want to switch MMC/SD to MQ.
>>>
>>> To me, there are two reasons for that (no secret agendas...)
>>>
>>> 1. To get away from the legacy codebase in the old block layer.
>>> Christoph and Jens have been very clear stating that the old block
>>> layer is in maintenance mode and should be phased out, and they
>>> asked explicitly for out help to do so. Currently
>>> MMC/SD is a big fat roadblock to these plans so it is win-win for
>>> MMC/SD and the block layer if we can just switch over to MQ.
>>>
>>> 2. My colleague Paolo Valente is working on the next generation
>>> block scheduler BFQ which has very promising potential for
>>> interactive loads. (Like taking a backup of your harddrive while
>>> playing 1080p video let's say.) Since the
>>> old block layer is no longer maintained, this scheduler will only
>>> be merged and made available for systems deploying MQ. He's
>>> already working full steam on that.
>>>
>>> I would like to make 1+2 happen in the next merge window
>>> ultimately, but yeah, maybe I'm overly optimistic. But I will sure
>>> try.
>>>
>>> Maybe I should add:
>>>
>>> 3. MQ is a better and future-proof fit for command queueing.
>>
>> MQ is not better - it is just different. Because mmc devices do not have
>> multiple hardware queues, blk-mq essentially offers nothing but a different
>> way of doing the same thing. And there are problems, such as blk-mq assumes
>> that the primary arbiter of whether a request can be issued is the queue
>> depth. As I wrote here:
>> https://marc.info/?l=linux-mmc&m=148336571720463&w=2
>> that is not the case for mmc, even with command queuing.
>>
> I guess it might benefit CMDQ since multi-thread can more easily let
> CMDQ achieve full performance. It is just my guess. We shall wait for
> the test result.
>
> Based on my own experience on developing CMDQ driver, some of the
> issues, like different
> partition and ioctl, can be solved by getting and putting mmc_host
> (mmc_claim_host/mmc_release_host).
> The key issue is Direct-CMD, It will be more complex to handle
> Direct-CMD with blk-mq,
> than doing it with current block layer. With current block layer, I
> just let CMDQ driver
> borrow existing non-CMDQ transfer routine, and turn back to CMDQ
> transfer routine
> after DCMD completes. But I'm not the effort we need with blk-mq.
>
> My key point is, please correct me if I'm wrong, shall we avoid binding
> CMDQ and
> non-CMDQ card layer together?
> To be honest, I don't think CMDQ is a good design. It will bring a lot
> of troubles.
> In my very own opinion, if we try to develop a single routine to
> support both CMDQ
> and non-CMDQ, it will be painful to both sides.
Not sure what you mean, but the patches linked below support DCMD and
non-DCMD for flush, and the regular approach for discards:
https://marc.info/?l=linux-mmc&m=148673270920906
CQE can be used for reads/writes only, or reads/writes/flushes. Everything
else is done the regular way.
>
> Thank you.
>
> Best regards,
> Hu Ziji
>
>> Also I wouldn't be surprise if BFQ needs some changes to work well with
>> command queuing.
>>
>> It would be better if blk-mq support was experimental until we can see how
>> well it works in practice.
>>
>
