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