Re: Some throughput tests with MQ and BFQ on MMC/SD

[Ziji Hu <huziji@marvell.com>]

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 <huziji@marvell.com> 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.

	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.
>