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

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

 



On Fri, Feb 17, 2017 at 12:53 PM, Ziji Hu <huziji@xxxxxxxxxxx> wrote:

>         I would like to suggest that you should try the multiple thread
>         test mode of iozone, since you are testing *Multi* Queue.

Good point. This target has only 2 CPUs but still, maybe it performs!

>         Besides, it seems that your eMMC transfer speed is quite low.
>         It is normal that read speed can reach more than 100MB/s in HS400.
>         Could you try a higher speed mode? The test result might be
>         limited by the bus clock frequency.

The iozone tests are done on an SDcard. And I only did read tests on
the eMMC I have.

It's because I'm afriad of wearing out my eMMC :(

But OK I'll just take the risk and run iozone on the eMMC.

>         Actually I have been following your thread for some time.
>         But currently I'm a little confused.
>         May I know the purpose of your patch?

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.

Yours,
Linus Walleij



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux