On 08/08/17 13:36, Ulf Hansson wrote: > On 8 August 2017 at 11:26, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: >> On 07/08/17 16:41, Ulf Hansson wrote: >>> On 21 July 2017 at 11:49, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: >>>> Hi >>>> >>>> Here is V4 of the hardware command queue patches without the software >>>> command queue patches. >>> >>> Adrian, again apologize for the delay. >>> >>> I am reviewing the series now and my intent is to provide comments on >>> each change separately during the week. >>> >>> However, a couple of overall thoughts: >>> >>> *) Could you please post some fresh performance measurements, such we >>> can get some real proof on why CMDQ is worth to be merged? If not >>> increased throughput, perhaps we can show some decreased I/O requests >>> latency!? >> >> HW CMDQ offers 25% - 50% better random multi-threaded I/O. I see a slight >> 2% drop in sequential read speed but no change to sequential write. > > Great, that satisfies my request! Could you please fold in this > information in one of the change-logs, which adds supports for the > CQE? Sure > >> >>> >>> **) I have spoken to Linus W offlist - and he is still working on the >>> blkmq port. Although we first need to continue with the >>> re-factorization of the mmc block/core code, to minimize the bad >>> impact of our big mmc claim host lock. We should expect a >>> re-submission of his series quite soonish. However, it's also likely >>> that we need yet another round of re-factoring, before we can complete >>> the port to blkmq. >>> >>> ***) The reason for bringing up **), is of course because I think >>> deploying CMDQ support would be better done on top of the blkmq >>> interface as it's better suited for these kind of device types. My >>> goal is to reach a better maintenance situation, using more modern mmc >>> block code. We have spoken about this before, however of course I also >>> don't want to delay the CMDQ series. Anyway, let's move forward and >>> see what path we end up taking. >> >> There is no advantage to holding up HW CMDQ. > > Maybe not. > > I haven't completed the review yet, but I guess you understand my > concerns on the impact of the blkmq port. If the blkmq port were ready there would be no problem. But I don't think it should be rushed. It would be better to throw more light on the issues. > > If I can get some promises about yours support (testing/reviewing/etc) > of the blkmq port series when going forward, that would of course > impact my decision on what path to pick. > > Does that sounds reasonable to you? Sure -- 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
