Re: [PATCH 0/6] mmc: block: command issue cleanups

On 24 January 2017 at 11:17, Linus Walleij wrote: > The function mmc_blk_issue_rw_rq() is hopelessly convoluted and > need to be refactored to it can be understood by humans. > > In the process I found some weird magic return values passed > around for no good reason. >

Re: [PATCH 0/6] mmc: block: command issue cleanups

+Maxime On 26 January 2017 at 09:07, Ulf Hansson <ulf.hans...@linaro.org> wrote: > On 24 January 2017 at 11:17, Linus Walleij <linus.wall...@linaro.org> wrote: >> The function mmc_blk_issue_rw_rq() is hopelessly convoluted and >> need to be refactored to it

Re: [PATCH v4] mmc: sdio: check the buffer address for sdio API

+Russell, Jens, Christoph, linux-block (asking for help in review) On 7 February 2017 at 01:54, Shawn Lin wrote: > It's fine if the host driver use PIO mode to transfer the > vmalloc area buffer but not for DMA mode. The sdio APIs haven't > provide the capability to

Re: Some throughput tests with MQ and BFQ on MMC/SD

[...] > > I would like to suggest that you should try the multiple thread > test mode of iozone, since you are testing *Multi* Queue. Yes. That seems reasonable. However, the most important part here is the comparison between the different code bases. > > Besides, it

Re: [PATCH V2] block: Fix secure erase

to mean either. Fix those. > > Signed-off-by: Adrian Hunter <adrian.hun...@intel.com> > Fixes: 288dab8a35a0 ("block: add a separate operation type for secure erase") For the mmc parts: Acked-by: Ulf Hansson <ulf.hans...@linaro.org> Jens, will you pick this up via

Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler

evices? Paolo and lots of other Linux users certainly do care about this. Moreover, I am still trying to understand what's the big deal to why you say no to BFQ as a legacy scheduler. Ideally it shouldn't cause you any maintenance burden and it doesn't make the removal of the legacy blk layer any more difficult, right? Kind regards Ulf Hansson -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler

That's really great news! I hope we get a possibility to meet and discuss the plans for this at Kernel summit/Linux Plumbers the next week! > > -- > Jens Axboe Kind regards Ulf Hansson -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a mess

Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler

otivation, if you continue to push him in different directions and without giving him any credibility - then at some point, you probably knows what will happen. > > The path forward is clear. It'd be a lot better to put some work behind > that, rather than continue this email thread. Yes, i

Re: Outstanding MQ questions from MMC

On 30 March 2017 at 14:42, Arnd Bergmann wrote: > On Wed, Mar 29, 2017 at 5:09 AM, Linus Walleij > wrote: >> Hi folks, >> >> I earlier left some unanswered questions in my MMC to MQ conversion series >> but I figured it is better if I collect them and

Re: Outstanding MQ questions from MMC

[...] >> Alternatively, I had this idea that we could translate blk requests into >> mmc commands and then have a (short fixed length) set of outstanding >> mmc commands in the device that always get done in order. The card >> detect and the user space I/O would then directly put mmc commands >>

[PATCH] MAINTAINERS: bfq: Add Paolo as maintainer for the BFQ I/O scheduler

Seems like this was forgotten in the bfq-series from Paolo. Let's do it now so people don't miss out involving Paolo for any future changes or when reporting bugs. Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org> --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff

Re: [PATCH 1/5] mmc: core: Delete bounce buffer Kconfig option

On 10 May 2017 at 10:24, Linus Walleij wrote: > This option is activated by all multiplatform configs and what > not so we almost always have it turned on, and the memory it > saves is negligible, even more so moving forward. The actual > bounce buffer only gets

[RFC PATCH 0/3] mmc: core: Prepare mmc host locking for blk-mq

instead. This series, so far untested, implements the idea from above. Sent as an RFC just to get peoples opinion of whether this is an approach that could work. Ulf Hansson (3): mmc: sdio: Don't use abort-able claim host method from SDIO IRQ thread mmc: core: Remove redundant abort-able claim host

[RFC PATCH 1/3] mmc: sdio: Don't use abort-able claim host method from SDIO IRQ thread

eld is protected from updates unless the host is claimed. When host->sdio_irqs has become zero, it means the SDIO func driver(s) has released the SDIO IRQ, then we can bail out and stop running the SDIO IRQ thread. Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org> --- drivers/mmc/cor

[RFC PATCH 2/3] mmc: core: Remove redundant abort-able claim host API

The only user of the abort-able claim host API was the SDIO IRQ thread, but as that use has now been removed, let's simplify the code and remove the API. Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org> --- drivers/mmc/core/core.c | 31 ++- drivers/mmc/core/

[RFC PATCH 3/3] mmc: core: Allow mmc block device to re-claim the host

to re-claim the host from different tasks/contexts, as we may have > 1 request to operate upon. Therefore, let's extend the mmc_claim_host() API to support reference counting for the mmc block device. Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org> --- drivers/mmc/core/cor

Re: [RFC PATCH 3/3] mmc: core: Allow mmc block device to re-claim the host

On 16 May 2017 at 15:24, Adrian Hunter <adrian.hun...@intel.com> wrote: > On 15/05/17 17:05, Ulf Hansson wrote: >> On 12 May 2017 at 10:36, Adrian Hunter <adrian.hun...@intel.com> wrote: >>> On 11/05/17 15:39, Ulf Hansson wrote: >>>> The current mmc

Re: [RFC PATCH 3/3] mmc: core: Allow mmc block device to re-claim the host

On 12 May 2017 at 10:36, Adrian Hunter <adrian.hun...@intel.com> wrote: > On 11/05/17 15:39, Ulf Hansson wrote: >> The current mmc block device implementation is tricky when it comes to >> claim and release of the host, while processing I/O requests. In principle >>

Re: [PATCH 2/5] mmc: core: Allocate per-request data using the block layer core

On 10 May 2017 at 10:24, Linus Walleij wrote: > The mmc_queue_req is a per-request state container the MMC core uses > to carry bounce buffers, pointers to asynchronous requests and so on. > Currently allocated as a static array of objects, then as a request > comes in,

Re: [PATCH 4/5] mmc: block: move single ioctl() commands to block requests

On 10 May 2017 at 10:24, Linus Walleij wrote: > This wraps single ioctl() commands into block requests using > the custom block layer request types REQ_OP_DRV_IN and > REQ_OP_DRV_OUT. > > By doing this we are loosening the grip on the big host lock, > since two calls to

Re: [PATCH 1/6 v2] mmc: core: Delete bounce buffer Kconfig option

On 18 May 2017 at 11:29, Linus Walleij wrote: > This option is activated by all multiplatform configs and what > not so we almost always have it turned on, and the memory it > saves is negligible, even more so moving forward. The actual > bounce buffer only gets

Re: [PATCH 5/6] mmc: debugfs: Move card status retrieveal into the block layer

[...] >> Seems like a bit of re-factoring/cleanup could help here as >> preparation step. I just posted a patch [1] cleaning up how the mmc >> block layer fetches the card's status. >> >> Perhaps that could at least simplify a bit for $subject patch, >> especially since it also makes

Re: [PATCH 5/6] mmc: debugfs: Move card status retrieveal into the block layer

[...] +#if IS_ENABLED(CONFIG_MMC_BLOCK) >>> >>> What wrong with a regular ifdefs stubs? Why do you need IS_ENABLED()? >> >> This is because the entire block layer can be compiled as a >> module. > > The block layer cannot be a module, but the MMC layer can. > >> I'm all for making

Re: [PATCH 5/6] mmc: debugfs: Move card status retrieveal into the block layer

On 19 May 2017 at 15:37, Linus Walleij wrote: > The debugfs file "status" (in e.g. /debug/mmc3/mmc3:0001) is > only available if and only if the card used is an (e)MMC or > SD card, not for SDIO, as can be seen from this guard in > mmc_add_card_debugfs(); > > if

Re: [PATCH 0/6] More MMC block core refactorings

On 19 May 2017 at 15:37, Linus Walleij wrote: > This series builds on top of the previous series that created > custom DRV_OP requests for ioctl() operations in MMC. > > The first patch is a suggestion from Christoph, the second > builds infrastructure for issuing more,

Re: [PATCH V8 01/14] mmc: core: Introduce host claiming by context

On 13 September 2017 at 13:40, Adrian Hunter wrote: > Currently the host can be claimed by a task. Change this so that the host > can be claimed by a context that may or may not be a task. This provides > for the host to be claimed by a block driver queue to support

Re: [PATCH 2/2 v6] mmc: block: Delete mmc_access_rpmb()

On 20 September 2017 at 10:02, Linus Walleij wrote: > This function is used by the block layer queue to bail out of > requests if the current request is towards an RPMB > "block device". > > This was done to avoid boot time scanning of this "block > device" which was

Re: [PATCH 1/2 v6] mmc: block: Convert RPMB to a character device

On 20 September 2017 at 10:02, Linus Walleij wrote: > The RPMB partition on the eMMC devices is a special area used > for storing cryptographically safe information signed by a > special secret key. To write and read records from this special > area, authentication is

Re: [PATCH V8 08/14] mmc: core: Add parameter use_blk_mq

On 13 September 2017 at 13:40, Adrian Hunter wrote: > Until mmc has blk-mq support fully implemented and tested, add a > parameter use_blk_mq, default to false unless config option MMC_MQ_DEFAULT > is selected. > > Signed-off-by: Adrian Hunter >

Re: [PATCH V8 00/14] mmc: Add Command Queue support

On 13 September 2017 at 13:40, Adrian Hunter wrote: > Hi > > Here is V8 of the hardware command queue patches without the software > command queue patches, now using blk-mq and now with blk-mq support for > non-CQE I/O. > > After the unacceptable debacle of the last

Re: [PATCH V9 13/15] mmc: block: Add CQE and blk-mq support

[...] >> MQ code that doesn't perform and therefore we cannot switch seamlessly >> to MQ. > > I think that switching seamlessly to blk-mq in short/medium-term > is not possible (SCSI tried and failed to do so). The changes to > the old path are very complex and besides affecting performance >

Re: [PATCH V8 00/14] mmc: Add Command Queue support

[...] I have also run some test on my ux500 board and enabling the blkmq path via the new MMC Kconfig option. My idea was to run some iozone comparisons between the legacy path and the new blkmq path, but I just couldn't get to that point because of the following errors.

Re: [PATCH V8 00/14] mmc: Add Command Queue support

On 21 September 2017 at 11:44, Adrian Hunter <adrian.hun...@intel.com> wrote: > On 21/09/17 12:01, Ulf Hansson wrote: >> On 13 September 2017 at 13:40, Adrian Hunter <adrian.hun...@intel.com> wrote: >>> Hi >>> >>> Here is V8 of the hardware comman

Re: [PATCH V9 13/15] mmc: block: Add CQE and blk-mq support

On 5 October 2017 at 12:55, Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com> wrote: > On Wednesday, October 04, 2017 11:48:27 AM Ulf Hansson wrote: >> [...] >> >> >> MQ code that doesn't perform and therefore we cannot switch seamlessly >> >> to MQ

Re: [PATCH V9 00/15] mmc: Add Command Queue support

On 27 September 2017 at 00:25, Ulf Hansson <ulf.hans...@linaro.org> wrote: > On 22 September 2017 at 14:36, Adrian Hunter <adrian.hun...@intel.com> wrote: >> Hi >> >> Here is V9 of the hardware command queue patches without the software >> command queue pat

Re: [PATCH V8 00/14] mmc: Add Command Queue support

On 12 October 2017 at 10:08, Linus Walleij <linus.wall...@linaro.org> wrote: > On Wed, Oct 11, 2017 at 3:58 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: > >> Actually completing the request in the ->done callback, may still be >> possible, because in principle

Re: [PATCH V7 00/10] mmc: Add Command Queue support

On 6 September 2017 at 09:20, Adrian Hunter <adrian.hun...@intel.com> wrote: > On 05/09/17 20:54, Ulf Hansson wrote: >> On 5 September 2017 at 10:10, Adrian Hunter <adrian.hun...@intel.com> wrote: >>> On 05/09/17 10:24, Ulf Hansson wrote: >>>> [...] >

Re: [PATCH V7 00/10] mmc: Add Command Queue support

[...] >>> >>> I can send blk-mq support for legacy requests in a few days if you like, but >>> I want to hear a better explanation of why you are delaying CQE support. >> >> That would be very nice, however be aware of that we are in the merge >> window, so I am not picking new material for 4.14

Re: [PATCH V7 00/10] mmc: Add Command Queue support

On 5 September 2017 at 10:10, Adrian Hunter <adrian.hun...@intel.com> wrote: > On 05/09/17 10:24, Ulf Hansson wrote: >> [...] >> >>>>> >>>>> I can send blk-mq support for legacy requests in a few days if you like, >>>>> but >

Re: [PATCH V9 00/15] mmc: Add Command Queue support

On 22 September 2017 at 14:36, Adrian Hunter wrote: > Hi > > Here is V9 of the hardware command queue patches without the software > command queue patches, now using blk-mq and now with blk-mq support for > non-CQE I/O. > > HW CMDQ offers 25% - 50% better random

Re: [PATCH V9 09/15] mmc: core: Add parameter use_blk_mq

On 22 September 2017 at 14:36, Adrian Hunter wrote: > Until mmc has blk-mq support fully implemented and tested, add a > parameter use_blk_mq, default to false unless config option MMC_MQ_DEFAULT > is selected. > > Signed-off-by: Adrian Hunter

Re: [PATCH V9 12/15] mmc: core: Export mmc_retune_hold_now() and mmc_retune_release()

On 22 September 2017 at 14:37, Adrian Hunter wrote: > Export mmc_retune_hold_now() and mmc_retune_release() so they can be used > by the block driver. > > Signed-off-by: Adrian Hunter I decided to squash patch 10/11/12 as those are all related

Re: [PATCH V9 13/15] mmc: block: Add CQE and blk-mq support

On 22 September 2017 at 14:37, Adrian Hunter wrote: > Add CQE support to the block driver, including: > - optionally using DCMD for flush requests > - "manually" issuing discard requests > - issuing read / write requests to the CQE > - supporting

Re: [PATCH V7 00/10] mmc: Add Command Queue support

+ Christoph On 1 September 2017 at 13:42, Adrian Hunter wrote: > On 31/08/17 14:56, Adrian Hunter wrote: >> Here is V7 of the hardware command queue patches without the software >> command queue patches, now using blk-mq. >> >> HW CMDQ offers 25% - 50% better random

Re: [PATCH V7 00/10] mmc: Add Command Queue support

On 4 September 2017 at 09:06, Adrian Hunter <adrian.hun...@intel.com> wrote: > On 01/09/17 16:28, Adrian Hunter wrote: >> On 01/09/17 15:58, Ulf Hansson wrote: >>> + Christoph >>> >>> On 1 September 2017 at 13:42, Adrian Hunter <adrian.hun...@intel.com&

Re: [PATCH V6 02/12] mmc: block: Fix block status codes

On 25 August 2017 at 14:43, Adrian Hunter wrote: > Commit 2a842acab109 ("block: introduce new block status code type") changed > the error type but not in patches merged through the mmc tree, like > commit 0493f6fe5bde ("mmc: block: Move boot partition locking into a

Re: [PATCH V6 04/12] mmc: core: Turn off CQE before sending commands

Signed-off-by: Adrian Hunter <adrian.hun...@intel.com> > Reviewed-by: Linus Walleij <linus.wall...@linaro.org> > Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org> This one was already applied. Kind regards Uffe > --- > drivers/mmc/core/core.c | 9 + > 1

Re: [PATCH V6 03/12] mmc: host: Add CQE interface

On 25 August 2017 at 14:43, Adrian Hunter wrote: > Add CQE host operations, capabilities, and host members. > > Signed-off-by: Adrian Hunter I have now replaced the previous version with this one, applied for next! Thanks! Kind regards Uffe >

Re: [PATCH V6 01/12] mmc: core: Move mmc_start_areq() declaration

On 25 August 2017 at 14:43, Adrian Hunter wrote: > mmc_start_areq() is an internal mmc core API. Move the declaration > accordingly. > > Signed-off-by: Adrian Hunter Thanks, applied for next! Kind regards Uffe > --- > drivers/mmc/core/core.h

Re: [PATCH V8 00/14] mmc: Add Command Queue support

On 10 October 2017 at 15:31, Adrian Hunter <adrian.hun...@intel.com> wrote: > On 10/10/17 16:08, Ulf Hansson wrote: >> [...] >> >>>>>> >>>>>> I have also run some test on my ux500 board and enabling the blkmq >>>>&

Re: [PATCH V8 00/14] mmc: Add Command Queue support

On 11 October 2017 at 14:58, Adrian Hunter <adrian.hun...@intel.com> wrote: > On 11/10/17 15:13, Ulf Hansson wrote: >> On 10 October 2017 at 15:31, Adrian Hunter <adrian.hun...@intel.com> wrote: >>> On 10/10/17 16:08, Ulf Hansson wrote: >>>> [...] >&g

Re: [PATCH V8 00/14] mmc: Add Command Queue support

+ Bartlomiej [...] > So my conclusion is, let's start a as you suggested, by not completing > the request in ->done() as to maintain existing behavior. Then we can > address optimizations on top, which very likely will involve doing > changes to host drivers as well.

Re: [PATCH] block, bfq: remove batches of confusing ifdefs

<torva...@linux-foundation.org> > Tested-by: Luca Miccio <lucmic...@gmail.com> > Signed-off-by: Paolo Valente <paolo.vale...@linaro.org> This is a good step of improvement (one may consider more steps...), so feel free to add: Reviewed-by: Ulf Hansson

Re: [PATCH V14 13/24] mmc: block: Add blk-mq support

[...] > + > +enum mmc_issued mmc_blk_mq_issue_rq(struct mmc_queue *mq, struct request > *req) > +{ > + struct mmc_blk_data *md = mq->blkdata; > + struct mmc_card *card = md->queue.card; > + struct mmc_host *host = card->host; > + int ret;

Re: [PATCH V14 14/24] mmc: block: Add CQE support

On 21 November 2017 at 14:42, Adrian Hunter wrote: > Add CQE support to the block driver, including: > - optionally using DCMD for flush requests > - "manually" issuing discard requests > - issuing read / write requests to the CQE > - supporting

Re: [PATCH V14 13/24] mmc: block: Add blk-mq support

On 27 November 2017 at 11:20, Adrian Hunter <adrian.hun...@intel.com> wrote: > On 24/11/17 12:12, Ulf Hansson wrote: >> [...] >> >>> +/* Single sector read during recovery */ >>> +static void mmc_blk_ss_read(struct mmc_queue *mq, struct request *req) >

Re: [PATCH V14 13/24] mmc: block: Add blk-mq support

+ Jens, Paolo [...] >>> +static int mmc_blk_mq_issue_rw_rq(struct mmc_queue *mq, >>> + struct request *req) >>> +{ >>> + struct mmc_queue_req *mqrq = req_to_mmc_queue_req(req); >>> + struct mmc_host *host = mq->card->host; >>> + struct request

Re: [PATCH V14 17/24] mmc: block: blk-mq: Add support for direct completion

[...] > > diff --git a/drivers/mmc/core/queue.h b/drivers/mmc/core/queue.h > index 1d7d3b0afff8..c4271fa54f1a 100644 > --- a/drivers/mmc/core/queue.h > +++ b/drivers/mmc/core/queue.h > @@ -103,6 +103,7 @@ struct mmc_queue { > boolwaiting; > struct work_struct

Re: [PATCH V14 00/24] mmc: Add Command Queue support

Linus, Adrian, On 28 November 2017 at 10:42, Linus Walleij wrote: > On Tue, Nov 21, 2017 at 2:42 PM, Adrian Hunter > wrote: > >> Here is V14 of the hardware command queue patches without the software >> command queue patches, now using blk-mq

Re: [PATCH V14 00/24] mmc: Add Command Queue support

[...] >>> While we should look at changing blk-mq to give better workqueue >>> performance, >>> a bigger gain is likely to be made by adding a new host API to enable the >>> next already-prepared request to be issued directly from within ->done() >>> callback of the current request. > > I assume

Re: [PATCH V14 13/24] mmc: block: Add blk-mq support

[...] > +/* Single sector read during recovery */ > +static void mmc_blk_ss_read(struct mmc_queue *mq, struct request *req) Nitpick: I think mmc_blk_read_single() would be better as it is a more clear name. Would you mind changing it? > +{ > + struct mmc_queue_req *mqrq =

Re: [PATCH V14 07/24] mmc: block: Use data timeout in card_busy_detect()

On 22 November 2017 at 08:40, Adrian Hunter <adrian.hun...@intel.com> wrote: > On 21/11/17 17:39, Ulf Hansson wrote: >> On 21 November 2017 at 14:42, Adrian Hunter <adrian.hun...@intel.com> wrote: >>> card_busy_detect() has a 10 minute timeout. However the correct t

Re: [PATCH V14 03/24] mmc: core: Do not leave the block driver in a suspended state

On 21 November 2017 at 14:42, Adrian Hunter wrote: > The block driver must be resumed if the mmc bus fails to suspend the card. > > Signed-off-by: Adrian Hunter Thanks, applied for fixes and added a stable tag (I think v3.19+ is the first one we

Re: [PATCH V14 04/24] mmc: block: Ensure that debugfs files are removed

On 21 November 2017 at 14:42, Adrian Hunter wrote: > The card is not necessarily being removed, but the debugfs files must be > removed when the driver is removed, otherwise they will continue to exist > after unbinding the card from the driver. e.g. > > # echo

Re: [PATCH V14 02/24] mmc: block: Check return value of blk_get_request()

On 21 November 2017 at 14:42, Adrian Hunter wrote: > blk_get_request() can fail, always check the return value. > > Fixes: 0493f6fe5bde ("mmc: block: Move boot partition locking into a driver > op") > Fixes: 3ecd8cf23f88 ("mmc: block: move multi-ioctl() to use block

Re: [PATCH V14 01/24] mmc: block: Fix missing blk_put_request()

On 21 November 2017 at 14:42, Adrian Hunter wrote: > Ensure blk_get_request() is paired with blk_put_request(). > > Fixes: 0493f6fe5bde ("mmc: block: Move boot partition locking into a driver > op") > Fixes: 627c3ccfb46a ("mmc: debugfs: Move block debugfs into block

Re: [PATCH V14 07/24] mmc: block: Use data timeout in card_busy_detect()

On 21 November 2017 at 14:42, Adrian Hunter wrote: > card_busy_detect() has a 10 minute timeout. However the correct timeout is > the data timeout. Change card_busy_detect() to use the data timeout. Unfortunate I don't think there is "correct" timeout for this case. The

Re: [PATCH V13 03/10] mmc: block: Add blk-mq support

On 15 November 2017 at 14:07, Adrian Hunter <adrian.hun...@intel.com> wrote: > On 15/11/17 12:55, Ulf Hansson wrote: >> Linus, Adrian, >> >> Apologize for sidetracking the discussion, just wanted to add some >> minor comments. >> >> [...] >> &g

Re: [PATCH 00/12 v5] Multiqueue for MMC/SD

[...] >> Moreover, for reasons brought up while reviewing Adrian's series, >> regarding if mq is "ready", and because I see that the diff for patch >> 12 is small, I suggest that we just skip the step adding a Kconfig >> option to allow an opt-in of the mq path. In other words, *the* patch >>

Re: [PATCH V13 03/10] mmc: block: Add blk-mq support

Linus, Adrian, Apologize for sidetracking the discussion, just wanted to add some minor comments. [...] > >>> But what I think is nice in doing it around >>> each request is that since mmc_put_card() calls mmc_release_host() >>> contains this: >>> >>> if (--host->claim_cnt) { (...) >>> >>> So

Re: [PATCH 00/12 v5] Multiqueue for MMC/SD

On 10 November 2017 at 11:01, Linus Walleij wrote: > This is the fifth iteration of this patch set. > > I *HOPE* that we can scrap this patch set and merge Adrian's > patches instead, because they also bring CQE support which is > nice. I had some review comments on his

Re: high overhead of functions blkg_*stats_* in bfq

On 6 November 2017 at 03:21, Jens Axboe wrote: > On 11/05/2017 01:39 AM, Paolo Valente wrote: >> >>> Il giorno 18 ott 2017, alle ore 15:19, Tejun Heo ha >>> scritto: >>> >>> Hello, Paolo. >>> >>> On Tue, Oct 17, 2017 at 12:11:01PM +0200, Paolo Valente wrote:

Re: high overhead of functions blkg_*stats_* in bfq

On 6 November 2017 at 10:49, Paolo Valente <paolo.vale...@linaro.org> wrote: > >> Il giorno 06 nov 2017, alle ore 10:22, Ulf Hansson <ulf.hans...@linaro.org> >> ha scritto: >> >> On 6 November 2017 at 03:21, Jens Axboe <ax...@kernel.dk> wrote: &g

Re: [PATCH V13 06/10] mmc: sdhci-pci: Add CQHCI support for Intel GLK

On 3 November 2017 at 14:20, Adrian Hunter wrote: > Add CQHCI initialization and implement CQHCI operations for Intel GLK. > > Signed-off-by: Adrian Hunter This looks good to me! Kind regards Uffe > --- > drivers/mmc/host/Kconfig |

Re: [PATCH V13 09/10] mmc: block: blk-mq: Stop using card_busy_detect()

On 3 November 2017 at 14:20, Adrian Hunter wrote: > card_busy_detect() doesn't set a correct timeout, and it doesn't take care > of error status bits. Stop using it for blk-mq. I think this changelog isn't very descriptive. Could you please work on that for the next

Re: [PATCH V13 05/10] mmc: cqhci: support for command queue enabled host

On 3 November 2017 at 14:20, Adrian Hunter wrote: > From: Venkat Gopalakrishnan > > This patch adds CMDQ support for command-queue compatible > hosts. > > Command queue is added in eMMC-5.1 specification. This > enables the controller to process

Re: [PATCH V15 00/22] mmc: Add Command Queue support

On 29 November 2017 at 16:47, Ulf Hansson <ulf.hans...@linaro.org> wrote: > Hi Adrian, > > On 29 November 2017 at 14:40, Adrian Hunter <adrian.hun...@intel.com> wrote: >> Hi >> >> Here is V15 of the hardware command queue patches without the software >

Re: [PATCH V15 00/22] mmc: Add Command Queue support

On 5 December 2017 at 11:10, Linus Walleij <linus.wall...@linaro.org> wrote: > On Wed, Nov 29, 2017 at 4:47 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: > >> I have applied patches 1->19 for next. Deferring patch 21->23 for a while. >> >> For th

Re: [PATCH V12 2/5] mmc: block: Add blk-mq support

On 24 October 2017 at 10:40, Adrian Hunter wrote: > Define and use a blk-mq queue. Discards and flushes are processed > synchronously, but reads and writes asynchronously. In order to support > slow DMA unmapping, DMA unmapping is not done until after the next request >

Re: [PATCH V12 2/5] mmc: block: Add blk-mq support

>>> >>> -#define CMD_ERRORS \ >>> - (R1_OUT_OF_RANGE | /* Command argument out of range */ \ >>> -R1_ADDRESS_ERROR | /* Misaligned address */\ >>> +#define CMD_ERRORS_EXCL_OOR

Re: [PATCH 11/12 v4] mmc: block: issue requests in massive parallel

On 26 October 2017 at 14:57, Linus Walleij wrote: > This makes a crucial change to the issueing mechanism for the > MMC requests: > > Before commit "mmc: core: move the asynchronous post-processing" > some parallelism on the read/write requests was achieved by >

Re: [PATCH] mmc: block: Fix unsupported parallel dispatch of requests

On 21 August 2018 at 14:05, Adrian Hunter wrote: > The mmc block driver does not support parallel dispatch of requests. In > normal circumstances, all requests are anyway funneled through a single > work item, so parallel dispatch never happens. However it can happen if > there is no elevator. >

Re: [PATCH v2] block: BFQ default for single queue devices

s, around how to move this forward. However, let's hope they get convinced to try this out. When it comes to potential "performance" regressions, I am sure Paolo is standing-by to help out with BFQ changes, if needed. Moreover, we can always do a simple revert in worst case scenario, especially

Re: [PATCH 13/16] mmc: simplify queue initialization

; + * @subname: partition subname Drop subname :-) > + * > + * Initialise a MMC card request queue. > + */ > +int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card, > + spinlock_t *lock) > { [...] A very nice cleanup, thanks! Reviewed-by: Ulf Hansson Kind regards Uffe

Re: [PATCH 14/16] mmc: stop abusing the request queue_lock pointer

On 14 November 2018 at 17:02, Christoph Hellwig wrote: > mmc uses the block layer struct request pointer to indirect their own > lock to the mmc_queue structure, given that the original lock isn't > reachable outside of block.c. Add a lock pointer to struct mmc_queue > instead and stop

Re: [PATCH 6/6] mmc: stop abusing the request queue_lock pointer

On 16 November 2018 at 09:10, Christoph Hellwig wrote: > Replace the lock in mmc_blk_data that is only used through a pointer > in struct mmc_queue and to protect fields in that structure with > an actual lock in struct mmc_queue. > > Suggested-by: Ulf Hansson > Signed-off-by: