On 20/02/17 13:04, Ziji Hu wrote:

Hi Adrian,

On 2017/2/20 16:03, Adrian Hunter wrote:

quoted

On 17/02/17 15:22, Linus Walleij wrote:

quoted

On Fri, Feb 17, 2017 at 12:53 PM, Ziji Hu [off-list ref] wrote:

<snip>

quoted

quoted

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

quoted

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.