Do we really need to make any of the blk-mq scheduling modular?
--
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
Looks fine, even totally independent of any sched work, like most
of the cleanups following this one
Reviewed-by: Christoph Hellwig
--
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.k
On Wed, Jan 11, 2017 at 02:39:57PM -0700, Jens Axboe wrote:
> It's only used in blk-mq, kill it from the main exported header
> and kill the symbol export as well.
Looks fine,
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of
On Thu, Jan 12, 2017 at 05:28:45PM -0500, Mike Snitzer wrote:
> What is "incomplete" about request-based DM's BLOCK_PC support?
BLOCK_PC requests are always aomething issued by the driver itself
(for a broad defintion of the driver, aka everything under the block
layer that works together is a dri
On Thu, Jan 12, 2017 at 02:54:38PM -0700, Jens Axboe wrote:
> On Thu, Jan 12 2017, Bart Van Assche wrote:
> > On Wed, 2017-01-11 at 14:40 -0700, Jens Axboe wrote:
> > > @@ -2392,12 +2425,12 @@ int blk_mq_alloc_tag_set(struct blk_mq_tag_set
> > > *set)
> > > if (set->nr_hw_queues > nr_cpu_ids)
>
On Wed, Jan 11, 2017 at 02:39:59PM -0700, Jens Axboe wrote:
> This is in preparation for having another tag set available. Cleanup
> the parameters, and allow passing in of tags fo blk_mq_put_tag().
I've been playing around with this are a bit but never submitted
anything. Below is an untested me
Looks fine,
Reviewed-by: Christoph Hellwig
--
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
On 01/11/2017 10:39 PM, Jens Axboe wrote:
> Another year, another posting of this patchset. The previous posting
> was here:
>
> https://www.spinics.net/lists/kernel/msg2406106.html
>
> (yes, I've skipped v5, it was fixes on top of v4, not the rework).
>
> I've reworked bits of this to get rid o
On Wed, Jan 11, 2017 at 02:39:54PM -0700, Jens Axboe wrote:
> Prep patch for adding MQ ops as well, since doing anon unions with
> named initializers doesn't work on older compilers.
My gut feeling tells me MQ schedulers shouldn't share elevator_type.
I'll play around a bit with the code later to
On 01/11/2017 10:39 PM, Jens Axboe wrote:
> Another year, another posting of this patchset. The previous posting
> was here:
>
> https://www.spinics.net/lists/kernel/msg2406106.html
>
> (yes, I've skipped v5, it was fixes on top of v4, not the rework).
>
> I've reworked bits of this to get rid o
On 01/13/2017 09:15 AM, Hannes Reinecke wrote:
> On 01/11/2017 10:39 PM, Jens Axboe wrote:
>> Another year, another posting of this patchset. The previous posting
>> was here:
>>
>> https://www.spinics.net/lists/kernel/msg2406106.html
>>
>> (yes, I've skipped v5, it was fixes on top of v4, not the
On 01/11/2017 10:40 PM, Jens Axboe wrote:
> This adds a set of hooks that intercepts the blk-mq path of
> allocating/inserting/issuing/completing requests, allowing
> us to develop a scheduler within that framework.
>
> We reuse the existing elevator scheduler API on the registration
> side, but a
Hi all,
the first two fixes fix a regression in 4.10-rc1 where the data transfer
size for discard commands wasn't set properly, leading to hangs with
Hyper-V VMs. The use the new data transfer size helper added in patch 1
more widely.
--
To unsubscribe from this list: send the line "unsubscribe l
Without that we'll pass a wrong payload size in cmd->sdb, which
can lead to hangs with drivers that need the total transfer size.
Signed-off-by: Christoph Hellwig
Reported-by: Chris Valean
Reported-by: Dexuan Cui
Fixes: f9d03f96 ("block: improve handling of the magic discard payload")
---
driv
Now that we have the blk_rq_payload_bytes helper available to determine
the actual I/O size we don't need to mess around with __data_len for
WRITE SAME.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/sd.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/dr
The new blk_rq_payload_bytes generalizes the payload length hacks
that nvme_map_len did before.
Signed-off-by: Christoph Hellwig
---
drivers/nvme/host/fc.c | 5 ++---
drivers/nvme/host/nvme.h | 8
drivers/nvme/host/pci.c | 19 ---
drivers/nvme/host/rdma.c | 13 +
Add a helper to calculate the actual data transfer size for special
payload requests.
Signed-off-by: Christoph Hellwig
---
include/linux/blkdev.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index ff3d774..1ca8e8f 100644
--- a
On 01/13/2017 12:29 PM, Christoph Hellwig wrote:
> Add a helper to calculate the actual data transfer size for special
> payload requests.
>
> Signed-off-by: Christoph Hellwig
> ---
> include/linux/blkdev.h | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/include/linux/bl
On 01/13/2017 12:29 PM, Christoph Hellwig wrote:
> Without that we'll pass a wrong payload size in cmd->sdb, which
> can lead to hangs with drivers that need the total transfer size.
>
> Signed-off-by: Christoph Hellwig
> Reported-by: Chris Valean
> Reported-by: Dexuan Cui
> Fixes: f9d03f96 ("b
On 01/13/2017 12:29 PM, Christoph Hellwig wrote:
> The new blk_rq_payload_bytes generalizes the payload length hacks
> that nvme_map_len did before.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/nvme/host/fc.c | 5 ++---
> drivers/nvme/host/nvme.h | 8
> drivers/nvme/host/pci
On 01/13/2017 12:29 PM, Christoph Hellwig wrote:
> Now that we have the blk_rq_payload_bytes helper available to determine
> the actual I/O size we don't need to mess around with __data_len for
> WRITE SAME.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/scsi/sd.c | 17 +
>
On 01/13/2017 12:04 PM, Hannes Reinecke wrote:
> On 01/13/2017 09:15 AM, Hannes Reinecke wrote:
>> On 01/11/2017 10:39 PM, Jens Axboe wrote:
>>> Another year, another posting of this patchset. The previous posting
>>> was here:
>>>
>>> https://www.spinics.net/lists/kernel/msg2406106.html
>>>
>>> (y
The problem is that brd return -EIO due to alignment, and the old
code waited for the bio and then ignored the error. The new code
assumes if the submission is fine this is the method to pick and to
move on. We could revert some of this for now, but I think the right
thing to do is to stop abusin
Discard can return -EIO asynchronously if the alignment for the request
isn't suitable for the driver, which makes a proper fallback to other
methods in __blkdev_issue_zeroout impossible. Thus only issue a sync
discard from blkdev_issue_zeroout an don't try discard at all from
__blkdev_issue_zeroo
On Fri, Jan 13 2017, Christoph Hellwig wrote:
> Do we really need to make any of the blk-mq scheduling modular?
I think so - I want to be able to turn it on and off. And since we
already have a framework for this (see reply in other patch), I don't
see a reason NOT to do this.
--
Jens Axboe
--
On Fri, Jan 13 2017, Hannes Reinecke wrote:
> On 01/13/2017 09:15 AM, Hannes Reinecke wrote:
> > On 01/11/2017 10:39 PM, Jens Axboe wrote:
> >> Another year, another posting of this patchset. The previous posting
> >> was here:
> >>
> >> https://www.spinics.net/lists/kernel/msg2406106.html
> >>
> >
On Fri, Jan 13 2017, Hannes Reinecke wrote:
> On 01/13/2017 12:04 PM, Hannes Reinecke wrote:
> > On 01/13/2017 09:15 AM, Hannes Reinecke wrote:
> >> On 01/11/2017 10:39 PM, Jens Axboe wrote:
> >>> Another year, another posting of this patchset. The previous posting
> >>> was here:
> >>>
> >>> https
On Fri, Jan 13 2017, Christoph Hellwig wrote:
> On Wed, Jan 11, 2017 at 02:39:59PM -0700, Jens Axboe wrote:
> > This is in preparation for having another tag set available. Cleanup
> > the parameters, and allow passing in of tags fo blk_mq_put_tag().
>
> I've been playing around with this are a bi
On Fri, Jan 13 2017, Christoph Hellwig wrote:
> On Wed, Jan 11, 2017 at 02:39:54PM -0700, Jens Axboe wrote:
> > Prep patch for adding MQ ops as well, since doing anon unions with
> > named initializers doesn't work on older compilers.
>
> My gut feeling tells me MQ schedulers shouldn't share eleva
On 01/13/2017 04:04 AM, Hannes Reinecke wrote:
> On 01/13/2017 09:15 AM, Hannes Reinecke wrote:
>> On 01/11/2017 10:39 PM, Jens Axboe wrote:
>>> Another year, another posting of this patchset. The previous posting
>>> was here:
>>>
>>> https://www.spinics.net/lists/kernel/msg2406106.html
>>>
>>> (y
Use list_entry_rq() instead of open-coding it.
Signed-off-by: Geliang Tang
---
block/blk-core.c | 4 ++--
block/blk-mq.c | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index 61ba08c..3c254d9 100644
--- a/block/blk-core.c
+++ b/blo
Add fall through comment for ELEVATOR_INSERT_SORT_MERGE.
Signed-off-by: Geliang Tang
---
block/elevator.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/block/elevator.c b/block/elevator.c
index 40f0c04..6db8f89 100644
--- a/block/elevator.c
+++ b/block/elevator.c
@@ -638,6 +638,7 @@ void _
On 01/13/2017 04:23 PM, Jens Axboe wrote:
> On 01/13/2017 04:04 AM, Hannes Reinecke wrote:
>> On 01/13/2017 09:15 AM, Hannes Reinecke wrote:
>>> On 01/11/2017 10:39 PM, Jens Axboe wrote:
Another year, another posting of this patchset. The previous posting
was here:
https://www.s
On 01/13/2017 08:33 AM, Hannes Reinecke wrote:
> On 01/13/2017 04:23 PM, Jens Axboe wrote:
>> On 01/13/2017 04:04 AM, Hannes Reinecke wrote:
>>> On 01/13/2017 09:15 AM, Hannes Reinecke wrote:
On 01/11/2017 10:39 PM, Jens Axboe wrote:
> Another year, another posting of this patchset. The pr
Since we are in the memory reclaim path we need our recv work to be on a
workqueue that has WQ_MEM_RECLAIM set so we can avoid deadlocks. Also
set WQ_HIGHPRI since we are in the completion path for IO.
Signed-off-by: Josef Bacik
---
drivers/block/nbd.c | 15 ++-
1 file changed, 14 i
On Wed, Jan 11, 2017 at 08:13:02AM -0700, Jens Axboe wrote:
> On 01/11/2017 08:07 AM, Jens Axboe wrote:
> > On 01/11/2017 06:43 AM, Johannes Thumshirn wrote:
> >> Hi all,
> >>
> >> I'd like to attend LSF/MM and would like to discuss polling for block
> >> drivers.
> >>
> >> Currently there is blk-
On 01/12/2017 06:29 PM, Benjamin Marzinski wrote:
> On Thu, Jan 12, 2017 at 09:27:40AM +0100, Hannes Reinecke wrote:
>> On 01/11/2017 11:23 PM, Mike Snitzer wrote:
>>> On Wed, Jan 11 2017 at 4:44am -0500,
>>> Hannes Reinecke wrote:
>>>
Hi all,
I'd like to attend LSF/MM this year, a
On 01/13/2017 04:34 PM, Jens Axboe wrote:
> On 01/13/2017 08:33 AM, Hannes Reinecke wrote:
[ .. ]
>> Ah, indeed.
>> There is an ominous udev rule here, trying to switch to 'deadline'.
>>
>> # cat 60-ssd-scheduler.rules
>> # do not edit this file, it will be overwritten on update
>>
>> ACTION!="add"
On 01/13/2017 08:59 AM, Hannes Reinecke wrote:
> On 01/13/2017 04:34 PM, Jens Axboe wrote:
>> On 01/13/2017 08:33 AM, Hannes Reinecke wrote:
> [ .. ]
>>> Ah, indeed.
>>> There is an ominous udev rule here, trying to switch to 'deadline'.
>>>
>>> # cat 60-ssd-scheduler.rules
>>> # do not edit this f
On 01/13/2017 09:00 AM, Jens Axboe wrote:
> On 01/13/2017 08:59 AM, Hannes Reinecke wrote:
>> On 01/13/2017 04:34 PM, Jens Axboe wrote:
>>> On 01/13/2017 08:33 AM, Hannes Reinecke wrote:
>> [ .. ]
Ah, indeed.
There is an ominous udev rule here, trying to switch to 'deadline'.
#
On Fri, Jan 13 2017 at 10:56am -0500,
Hannes Reinecke wrote:
> On 01/12/2017 06:29 PM, Benjamin Marzinski wrote:
> > On Thu, Jan 12, 2017 at 09:27:40AM +0100, Hannes Reinecke wrote:
> >> On 01/11/2017 11:23 PM, Mike Snitzer wrote:
> >>> On Wed, Jan 11 2017 at 4:44am -0500,
> >>> Hannes Reinecke
On Fri, 2017-01-13 at 12:15 +0100, Hannes Reinecke wrote:
> On 01/11/2017 10:40 PM, Jens Axboe wrote:
> > This adds a set of hooks that intercepts the blk-mq path of
> > allocating/inserting/issuing/completing requests, allowing
> > us to develop a scheduler within that framework.
> >
> > We reuse
On Fri, Jan 13, 2017 at 12:15:17PM +0100, Hannes Reinecke wrote:
> On 01/11/2017 10:40 PM, Jens Axboe wrote:
> > This adds a set of hooks that intercepts the blk-mq path of
> > allocating/inserting/issuing/completing requests, allowing
> > us to develop a scheduler within that framework.
> >
> > W
On 01/13/2017 05:07 PM, Mike Snitzer wrote:
> On Fri, Jan 13 2017 at 10:56am -0500,
> Hannes Reinecke wrote:
>
>> On 01/12/2017 06:29 PM, Benjamin Marzinski wrote:
[ .. ]
>>> While I've daydreamed of rewriting the multipath tools multiple times,
>>> and having nothing aginst you doing it in conce
On 01/13/2017 05:41 PM, Omar Sandoval wrote:
> On Fri, Jan 13, 2017 at 12:15:17PM +0100, Hannes Reinecke wrote:
>> On 01/11/2017 10:40 PM, Jens Axboe wrote:
>>> This adds a set of hooks that intercepts the blk-mq path of
>>> allocating/inserting/issuing/completing requests, allowing
>>> us to devel
To prepare for dynamically adding new nbd devices to the system switch
from using an array for the nbd devices and instead use an idr. This
copies what loop does for keeping track of its devices.
Signed-off-by: Josef Bacik
---
drivers/block/nbd.c | 226 --
Reviewed-by: Sagi Grimberg
--
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
The offline CPUs need to assigned to something incase they come online
later, otherwise anyone using the mapping for things other than affinity
will have blank entries for that online CPU.
I don't really like the idea behind it. Back when we came up with
this code I had some discussion with Tho
We need to leave the block queues stopped if we're changing the tagset's
number of queues.
Umm, Don't we need to fail these requests? What am I missing?
Won't these requests block until timeout expiration and will
trigger error recovery again?
--
To unsubscribe from this list: send the line "u
diff --git a/block/blk-mq.c b/block/blk-mq.c
index a8e67a1..9b7ed03 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -2223,7 +2223,6 @@ static void blk_mq_queue_reinit(struct request_queue *q,
* we should change hctx numa_node according to new topology (this
* involves free an
Looks good,
Reviewed-by: Sagi Grimberg
--
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
If hardware queues are stopped for some event, like the device has been
suspended by power management, requests allocated on that hardware queue
are indefinitely stuck causing a queue freeze to wait forever.
I have a problem with this patch. IMO, this is a general issue so, so
why do we tie a
Hello,
I would like to attend LSF/MM with the goal to participate in the discussion
related to the OCSSDs - SMR, Hierarchical Interface, and Vector I/Os topic.
I am implementing the flash-friendly file system for the host-managed
SSD device model. When we started our project we haven't any restric
The current implementation of badblocks, where we consult the badblocks
list for every IO in the block driver works, and is a last option
failsafe, but from a user perspective, it isn't the easiest interface to
work with.
A while back, Dave Chinner had suggested a move towards smarter
handling, an
On 01/13/2017 09:02 AM, Jens Axboe wrote:
> Also, would be great if you could pull:
>
> git://git.kernel.dk/linux-block blk-mq-sched
>
> into current 'master' and see if it still reproduces. I expect that it
> will, but just want to ensure that it's a problem in the current code
> base as well.
Add a helper to calculate the actual data transfer size for special
payload requests.
Signed-off-by: Christoph Hellwig
---
include/linux/blkdev.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index ff3d774..1ca8e8f 100644
--
Looks good,
Reviewed-by: Sagi Grimberg
--
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
This looks good,
Reviewed-by: Sagi Grimberg
--
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
Looks good,
Reviewed-by: Sagi Grimberg
--
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
On Fri, Jan 13 2017, Christoph Hellwig wrote:
> Hi all,
>
> the first two fixes fix a regression in 4.10-rc1 where the data transfer
> size for discard commands wasn't set properly, leading to hangs with
> Hyper-V VMs. The use the new data transfer size helper added in patch 1
> more widely.
Add
On Fri, Jan 13 2017, Christoph Hellwig wrote:
> Discard can return -EIO asynchronously if the alignment for the request
> isn't suitable for the driver, which makes a proper fallback to other
> methods in __blkdev_issue_zeroout impossible. Thus only issue a sync
> discard from blkdev_issue_zeroout
Hey Josef,
Since we are in the memory reclaim path we need our recv work to be on a
workqueue that has WQ_MEM_RECLAIM set so we can avoid deadlocks. Also
set WQ_HIGHPRI since we are in the completion path for IO.
Really a workqueue per device?? Did this really give performance
advantage? Can
Hey Josef,
To prepare for dynamically adding new nbd devices to the system switch
from using an array for the nbd devices and instead use an idr. This
copies what loop does for keeping track of its devices.
I think ida_simple_* is simpler and sufficient here isn't it?
--
To unsubscribe from t
On 01/13/2017 12:04 PM, Josef Bacik wrote:
> To prepare for dynamically adding new nbd devices to the system switch
> from using an array for the nbd devices and instead use an idr. This
> copies what loop does for keeping track of its devices.
What's this against? Doesn't apply to the 4.11 branc
Original Message
Subject: [LSF/MM TOPIC] Badblocks checking/representation in filesystems
Sent: Jan 13, 2017 1:40 PM
From: "Verma, Vishal L"
To: lsf...@lists.linux-foundation.org
Cc: linux-nvd...@lists.01.org, linux-block@vger.kernel.org,
linux-fsde...@vger.kernel.org
> The current im
This past year has seen a lot of new DAX development. We have added support
for fsync/msync, moved to the new iomap I/O data structure, introduced radix
tree based locking, re-enabled PMD support (twice!), and have fixed a bunch of
bugs.
We still have a lot of work to do, though, and I'd like to
On 01/14, Slava Dubeyko wrote:
>
> Original Message
> Subject: [LSF/MM TOPIC] Badblocks checking/representation in filesystems
> Sent: Jan 13, 2017 1:40 PM
> From: "Verma, Vishal L"
> To: lsf...@lists.linux-foundation.org
> Cc: linux-nvd...@lists.01.org, linux-block@vger.kernel.org,
>
> On Jan 13, 2017, at 5:24 PM, Sagi Grimberg wrote:
>
> Hey Josef,
>
>> Since we are in the memory reclaim path we need our recv work to be on a
>> workqueue that has WQ_MEM_RECLAIM set so we can avoid deadlocks. Also
>> set WQ_HIGHPRI since we are in the completion path for IO.
>
> Really a
> On Jan 13, 2017, at 5:41 PM, Sagi Grimberg wrote:
>
> Hey Josef,
>
>> To prepare for dynamically adding new nbd devices to the system switch
>> from using an array for the nbd devices and instead use an idr. This
>> copies what loop does for keeping track of its devices.
>
> I think ida_sim
Hi,
I'd like to attend LSF/MM again this year to discuss topics in blk-mq,
Btrfs, and the VFS.
I've been working on the blk-mq I/O scheduling framework [1] with Jens.
Once that is finalized, the next step is a proper multiqueue scheduler.
I've put together a prototype with a few basic ideas [2],
70 matches
Mail list logo