On 20/02/17 13:04, Ziji Hu wrote: > Hi Adrian, > > On 2017/2/20 16:03, Adrian Hunter wrote: >> On 17/02/17 15:22, Linus Walleij wrote: >>> On Fri, Feb 17, 2017 at 12:53 PM, Ziji Hu <huziji@xxxxxxxxxxx> wrote: > <snip> >>> 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 > >> 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. >> > -- 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
