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

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

 



Hi Linus,

On 2017/2/17 21:22, Linus Walleij wrote:
> 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!
>
	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
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux