> -----Original Message----- > From: Linus Walleij [mailto:linus.wall...@linaro.org] > Sent: Thursday, October 26, 2017 5:20 PM > To: Hunter, Adrian <adrian.hun...@intel.com> > Cc: linux-...@vger.kernel.org; Ulf Hansson <ulf.hans...@linaro.org>; > linux-block <linux-block@vger.kernel.org>; Jens Axboe <ax...@kernel.dk>; > Christoph Hellwig <h...@lst.de>; Arnd Bergmann <a...@arndb.de>; > Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com>; Paolo Valente > <paolo.vale...@linaro.org>; Avri Altman <avri.alt...@sandisk.com> > Subject: Re: [PATCH 00/12 v4] multiqueue for MMC/SD > > On Thu, Oct 26, 2017 at 3:34 PM, Adrian Hunter <adrian.hun...@intel.com> > wrote: > > On 26/10/17 15:57, Linus Walleij wrote: > >> In my opinion this is also a better fit for command queueuing. > > > > Not true. CQE support worked perfectly before blk-mq and did not > > depend on blk-mq in any way. Obviously the current CQE patch set > > actually implements the CQE requirements for blk-mq - which this patch set > does not. > > What I mean is that the CQE code will likely look better on top of these > refactorings. > > But as I say it is a matter of taste. I just love the looks of my own code as > much as the next programmer so I can't judge that. Let's see what the > reviewers say.
It doesn't look ready. There seems still to be 2 task switches between each transfer. mmc_blk_rw_done_error() is still using the messy error handling and doesn’t handle retries e.g. 'retry' is a local variable so it can't count the number of retries now that there is no loop. > >> It sounds simple but I bet this drives a truck through Adrians patch > >> series. Sorry. :( > > > > I waited a long time for your patches but I had to give up waiting > > when Ulf belated insisted on blk-mq before CQE. I am not sure what > > you are expecting now it seems too late. > > Too late for what? It's just a patch set, I don't really have a deadline for > this or > anything. As I explained above I have been working on this all the time, the > problem was that I was/am not smart enough to find that solution for host > claiming by context. Too late to go before CQE. All the blk-mq work is now in the CQE patchset. > > The host claiming by context was merged a month ago and now I have > understood that I can use that and rebased my patches on it. Slow learner, I > guess. > > If you feel it is ungrateful that you have put in so much work and things are > not getting merged, and you feel your patches deserve to be merged first > (because of human nature reasons) I can empathize with that. It's sad that > your patches are at v12. Also I see that patch 4 bears the signoffs of a > significant team at CodeAurora, so they are likely as impatient. It is important that you understand that this has nothing to do with "human nature reasons". Linux distributions use upstream kernels. ChromeOS has an "upstream first" policy. Delaying features for long periods has real-world consequences. When people ask, what kernel should they use, we expect to reply, just use mainline.
