Hi Linus,
On 2017/2/17 21:22, Linus Walleij wrote:
> On Fri, Feb 17, 2017 at 12:53 PM, Ziji Hu <[email protected]> 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!
>
In my very own opinion, (although I'm not the expert of marketing),
quad-core platforms will be more and more popular.
Quad-core might have a different result, especially when we are
testing multiple threads.
>> 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, there is a parameter to limit the size of test file in iozone.
I'm not sure why you need to scan the whole eMMC. But I personally
believe it is unnecessary.
Sorry for delay reply. Hope your eMMC is not broken yet. :p
eMMC usually contains much more physical pages than the capacity
it shows. Thus I guess your eMMC should be fine unless you torture
it by entirely writing it again and again.
>> 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.
I see. Thank you for the details.
>
> Maybe I should add:
>
> 3. MQ is a better and future-proof fit for command queueing.
I strongly agree with you on it.
Thank you.
Best regards,
Hu Ziji
>
> Yours,
> Linus Walleij
>
