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? > >> >> **) 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 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? [...] Kind regards Uffe -- 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
