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

> Il giorno 26 ott 2016, alle ore 18:12, Jens Axboe ha > scritto: > > On 10/26/2016 10:04 AM, Paolo Valente wrote: >> >>> Il giorno 26 ott 2016, alle ore 17:32, Jens Axboe ha >>> scritto: >>> >>> On 10/26/2016 09:29 AM, Christoph Hellwig wrote: On

[PATCH v5 14/14] nvme: Use BLK_MQ_S_STOPPED instead of QUEUE_FLAG_STOPPED in blk-mq code

Make nvme_requeue_req() check BLK_MQ_S_STOPPED instead of QUEUE_FLAG_STOPPED. Remove the QUEUE_FLAG_STOPPED manipulations that became superfluous because of this change. Change blk_queue_stopped() tests into blk_mq_queue_stopped(). This patch fixes a race condition: using

[PATCH v5 13/14] nvme: Fix a race condition related to stopping queues

Avoid that nvme_queue_rq() is still running when nvme_stop_queues() returns. Signed-off-by: Bart Van Assche Cc: Keith Busch Cc: Sagi Grimberg Cc: Christoph Hellwig --- drivers/nvme/host/core.c | 2 +- 1 file

[PATCH v5 12/14] SRP transport, scsi-mq: Wait for .queue_rq() if necessary

Ensure that if scsi-mq is enabled that scsi_internal_device_block() waits until ongoing shost->hostt->queuecommand() calls have finished. Signed-off-by: Bart Van Assche Cc: James Bottomley Cc: Martin K. Petersen

[PATCH v5 11/14] SRP transport: Move queuecommand() wait code to SCSI core

Additionally, rename srp_wait_for_queuecommand() into scsi_wait_for_queuecommand() and add a comment about the queuecommand() call from scsi_send_eh_cmnd(). Signed-off-by: Bart Van Assche Cc: James Bottomley Cc: Martin K. Petersen

[PATCH v5 10/14] dm: Fix a race condition related to stopping and starting queues

Ensure that all ongoing dm_mq_queue_rq() and dm_mq_requeue_request() calls have stopped before setting the "queue stopped" flag. This allows to remove the "queue stopped" test from dm_mq_queue_rq() and dm_mq_requeue_request(). This patch fixes a race condition because dm_mq_queue_rq() is called

[PATCH v5 09/14] dm: Use BLK_MQ_S_STOPPED instead of QUEUE_FLAG_STOPPED in blk-mq code

Instead of manipulating both QUEUE_FLAG_STOPPED and BLK_MQ_S_STOPPED in the dm start and stop queue functions, only manipulate the latter flag. Change blk_queue_stopped() tests into blk_mq_queue_stopped(). Signed-off-by: Bart Van Assche Acked-by: Mike Snitzer

[PATCH v5 08/14] blk-mq: Add a kick_requeue_list argument to blk_mq_requeue_request()

Most blk_mq_requeue_request() and blk_mq_add_to_requeue_list() calls are followed by kicking the requeue list. Hence add an argument to these two functions that allows to kick the requeue list. This was proposed by Christoph Hellwig. Signed-off-by: Bart Van Assche

[PATCH v5 04/14] blk-mq: Move more code into blk_mq_direct_issue_request()

Move the "hctx stopped" test and the insert request calls into blk_mq_direct_issue_request(). Rename that function into blk_mq_try_issue_directly() to reflect its new semantics. Pass the hctx pointer to that function instead of looking it up a second time. These changes avoid that code has to be

[PATCH v5 05/14] blk-mq: Avoid that requeueing starts stopped queues

Since blk_mq_requeue_work() starts stopped queues and since execution of this function can be scheduled after a queue has been stopped it is not possible to stop queues without using an additional state variable to track whether or not the queue has been stopped. Hence modify blk_mq_requeue_work()

[PATCH v5 0/14] Fix race conditions related to stopping block layer queues

Hello Jens, Multiple block drivers need the functionality to stop a request queue and to wait until all ongoing request_fn() / queue_rq() calls have finished without waiting until all outstanding requests have finished. Hence this patch series that introduces the blk_mq_quiesce_queue()

[PATCH v5 02/14] blk-mq: Introduce blk_mq_hctx_stopped()

Multiple functions test the BLK_MQ_S_STOPPED bit so introduce a helper function that performs this test. Signed-off-by: Bart Van Assche Reviewed-by: Ming Lei Reviewed-by: Hannes Reinecke Reviewed-by: Johannes Thumshirn

[PATCH v5 03/14] blk-mq: Introduce blk_mq_queue_stopped()

The function blk_queue_stopped() allows to test whether or not a traditional request queue has been stopped. Introduce a helper function that allows block drivers to query easily whether or not one or more hardware contexts of a blk-mq queue have been stopped. Signed-off-by: Bart Van Assche

[PATCH 2/2] blk-mq: immediately dispatch big size request

This is corresponding part for blk-mq. Disk with multiple hardware queues doesn't need this as we only hold 1 request at most. Signed-off-by: Shaohua Li --- block/blk-mq.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/block/blk-mq.c b/block/blk-mq.c

[PATCH 1/2] block: immediately dispatch big size request

Currently block plug holds up to 16 non-mergeable requests. This makes sense if the request size is small, eg, reduce lock contention. But if request size is big enough, we don't need to worry about lock contention. Holding such request makes no sense and it lows the disk utilization. In

Re: [PATCH] blk-mq: Always schedule hctx->next_cpu

On 09/27/2016 09:24 PM, Gabriel Krisman Bertazi wrote: Commit 0e87e58bf60e ("blk-mq: improve warning for running a queue on the wrong CPU") attempts to avoid triggering the WARN_ON in __blk_mq_run_hw_queue when the expected CPU is dead. Problem is, in the last batch execution before round

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

On Fri, Oct 28, 2016 at 5:29 PM, Christoph Hellwig wrote: > On Fri, Oct 28, 2016 at 11:32:21AM +0200, Linus Walleij wrote: >> So I'm not just complaining by the way, I'm trying to fix this. Also >> Bartlomiej from Samsung has done some stabs at switching MMC/SD >> to blk-mq. I

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

On Fri, Oct 28, 2016 at 4:22 PM, Jens Axboe wrote: > On 10/28/2016 03:32 AM, Linus Walleij wrote: >> >> This is without using Bartlomiej's clever hack to pretend we have >> 2 elements in the HW queue though. His early tests indicate that >> it doesn't help much: the performance

Re: [PATCH 2/3] iopmem : Add a block device driver for PCIe attached IO memory.

Hi Christoph, Thanks so much for the detailed review of the code! Even though by the sounds of things we will be moving to device dax and most of this is moot. Still, it's great to get some feedback and learn a few things. I've given some responses below. On 28/10/16 12:45 AM, Christoph Hellwig

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

On Fri, Oct 28, 2016 at 08:17:01AM -0600, Jens Axboe wrote: > On 10/28/2016 12:36 AM, Ulf Hansson wrote: > > You have been pushing Paolo in different directions throughout the > > years with his work in BFQ, wasting lots of his time/effort. > I have not. Various entities have advised Paolo

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

On Friday, October 28, 2016 9:30:07 AM CEST Jens Axboe wrote: > On 10/28/2016 03:32 AM, Linus Walleij wrote: > > The patch to enable MQ looks like this: > > https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-stericsson.git/commit/?h=mmc-mq=8f79b527e2e854071d8da019451da68d4753f71d > > BTW,

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

Hi, On Friday, October 28, 2016 09:30:07 AM Jens Axboe wrote: > On 10/28/2016 03:32 AM, Linus Walleij wrote: > > The patch to enable MQ looks like this: > > https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-stericsson.git/commit/?h=mmc-mq=8f79b527e2e854071d8da019451da68d4753f71d > >

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

On 10/28/2016 03:32 AM, Linus Walleij wrote: The patch to enable MQ looks like this: https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-stericsson.git/commit/?h=mmc-mq=8f79b527e2e854071d8da019451da68d4753f71d BTW, another viable "hack" for the depth issue would be to expose more than

Re: clean up block ops defintions

On 10/25/2016 06:01 AM, Christoph Hellwig wrote: Hi Jens, any comments on this series? I addition to fixing up the zoned command direction issue it's also the base for some more work that I'm doing at the moment, so I'd really like to know if you're fine with the direction. I think it looks

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

On 10/28/2016 12:36 AM, Ulf Hansson wrote: [...] 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,

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

On Fri, Oct 28, 2016 at 2:07 PM, Arnd Bergmann wrote: >> > I don't think that's an accurate statement. In terms of coverage, most >> > drivers do support blk-mq. Anything SCSI, nvme, virtio-blk, SATA runs on >> > (or can run on) top of blk-mq. >> >> Well, I just used "git grep" and

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

On Thursday, October 27, 2016 8:13:08 PM CEST Ulf Hansson wrote: > On 27 October 2016 at 19:43, Jens Axboe wrote: > > On 10/27/2016 11:32 AM, Ulf Hansson wrote: > >> > >> [...] > >> > >>> > >>> I'm hesistant to add a new scheduler because it's very easy to add, very > >>>

Re: REQ_OP for zeroing, was Re: [dm-devel] [PATCH 1/4] brd: handle misaligned discard

On Wed, 26 Oct 2016, Christoph Hellwig wrote: > On Wed, Oct 26, 2016 at 05:46:11PM -0400, Mikulas Patocka wrote: > > I think the proper thing would be to move "discard_zeroes_data" flag into > > the bio itself - there would be REQ_OP_DISCARD and REQ_OP_DISCARD_ZERO - > > and if the device

Re: [dm-devel] [PATCH 1/4] brd: handle misaligned discard

On Wed, 26 Oct 2016, Bart Van Assche wrote: > On 10/26/2016 02:46 PM, Mikulas Patocka wrote: > > I don't like the idea of complicating the code by turning discards into > > writes. > > That's not what my patch series does. The only writes added by my patch series > are those for the

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

On Fri, Oct 28, 2016 at 12:27 AM, Linus Walleij wrote: > On Thu, Oct 27, 2016 at 11:08 PM, Jens Axboe wrote: > >> blk-mq has evolved to support a variety of devices, there's nothing >> special about mmc that can't work well within that framework. > >

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

On Thu 27-10-16 10:26:18, Jens Axboe wrote: > On 10/27/2016 03:26 AM, Jan Kara wrote: > >On Wed 26-10-16 10:12:38, Jens Axboe wrote: > >>On 10/26/2016 10:04 AM, Paolo Valente wrote: > >>> > Il giorno 26 ott 2016, alle ore 17:32, Jens Axboe ha > scritto: > > On

Re: [PATCH 6/7] block: better op and flags encoding

> > void init_request_from_bio(struct request *req, struct bio *bio) > > { > > req->cmd_type = REQ_TYPE_FS; > > - > > - req->cmd_flags |= bio->bi_opf & REQ_COMMON_MASK; > > Don't we still have to init cmd_flags from bi_opf at some point in the > non-mq path? We now pass all of

Re: [PATCH 5/7] block: split out request-only flags into a new namespace

On Thu, Oct 20, 2016 at 8:12 AM, Christoph Hellwig wrote: > A lot of the REQ_* flags are only used on struct requests, and only of > use to the block layer and a few drivers that dig into struct request > internals. > > This patch adds a new req_flags_t rq_flags field to struct

Re: [PATCH 4/7] block: replace REQ_THROTTLED with a bio flag

On Thu, Oct 20, 2016 at 8:12 AM, Christoph Hellwig wrote: > It's the last bio-only REQ_* flag, and we have space for it in the bio > bi_flags field. > > Signed-off-by: Christoph Hellwig > --- > block/blk-throttle.c | 10 +- > include/linux/blk_types.h | 8

Re: [PATCH 3/3] iopmem : Add documentation for iopmem driver

I'd say please fold this into the previous patch. -- 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 2/3] iopmem : Add a block device driver for PCIe attached IO memory.

> Signed-off-by: Stephen Bates FYI, that address has bounced throught the whole thread for me, replacing it with a known good one for now. > + * This driver is heavily based on drivers/block/pmem.c. > + * Copyright (c) 2014, Intel Corporation. > + * Copyright (C) 2007 Nick

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

[...] > >> 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? > > > Not sure I can state it