On Wed, 2018-01-17 at 23:36 -0500, Mike Snitzer wrote:
> On Wed, Jan 17 2018 at 11:06pm -0500,
> Ming Lei wrote:
>
> > If we run into blk_mq_request_direct_issue(), when queue is busy,
> > we
> > don't want to dispatch this request into hctx->dispatch_list, and
> > what we need to do is to return
From: Tang Junhui
Hello Coly:
>It is because of ca->set->error_decay. When error_decay is set, bcache
>tries to do an exponential decay for error count. That is, error numbers
>is decaying against the quantity of io count, this is to avoid long time
>accumulated errors exceeds error_limit and tr
On 1/17/18 9:06 PM, Ming Lei wrote:
> If we run into blk_mq_request_direct_issue(), when queue is busy, we
> don't want to dispatch this request into hctx->dispatch_list, and
> what we need to do is to return the queue busy info to caller, so
> that caller can deal with it well.
Thanks for fixing
On Wed, Jan 17 2018 at 11:06pm -0500,
Ming Lei wrote:
> If we run into blk_mq_request_direct_issue(), when queue is busy, we
> don't want to dispatch this request into hctx->dispatch_list, and
> what we need to do is to return the queue busy info to caller, so
> that caller can deal with it well.
If we run into blk_mq_request_direct_issue(), when queue is busy, we
don't want to dispatch this request into hctx->dispatch_list, and
what we need to do is to return the queue busy info to caller, so
that caller can deal with it well.
Fixes: 396eaf21ee ("blk-mq: improve DM's blk-mq IO merging via
On Wed, Jan 17, 2018 at 10:49:58PM -0500, Mike Snitzer wrote:
> On Wed, Jan 17 2018 at 10:39pm -0500,
> Ming Lei wrote:
>
> > On Wed, Jan 17, 2018 at 10:33:35PM -0500, Mike Snitzer wrote:
> > > On Wed, Jan 17 2018 at 7:54P -0500,
> > > Mike Snitzer wrote:
> > >
> > > > But sure, I suppose the
On Wed, Jan 17 2018 at 10:39pm -0500,
Ming Lei wrote:
> On Wed, Jan 17, 2018 at 10:33:35PM -0500, Mike Snitzer wrote:
> > On Wed, Jan 17 2018 at 7:54P -0500,
> > Mike Snitzer wrote:
> >
> > > But sure, I suppose there is something I missed when refactoring Ming's
> > > change to get it accept
On Wed, Jan 17, 2018 at 10:37:23PM -0500, Mike Snitzer wrote:
> On Wed, Jan 17 2018 at 10:25pm -0500,
> Ming Lei wrote:
>
> > Hi Mike,
> >
> > On Wed, Jan 17, 2018 at 11:25:57AM -0500, Mike Snitzer wrote:
> > > From: Ming Lei
> > >
> > > blk_insert_cloned_request() is called in the fast path o
On Wed, Jan 17, 2018 at 10:33:35PM -0500, Mike Snitzer wrote:
> On Wed, Jan 17 2018 at 7:54P -0500,
> Mike Snitzer wrote:
>
> > But sure, I suppose there is something I missed when refactoring Ming's
> > change to get it acceptable for upstream. I went over the mechanical
> > nature of what I
On Wed, Jan 17 2018 at 10:25pm -0500,
Ming Lei wrote:
> Hi Mike,
>
> On Wed, Jan 17, 2018 at 11:25:57AM -0500, Mike Snitzer wrote:
> > From: Ming Lei
> >
> > blk_insert_cloned_request() is called in the fast path of a dm-rq driver
> > (e.g. blk-mq request-based DM mpath). blk_insert_cloned_re
On Wed, Jan 17 2018 at 7:54P -0500,
Mike Snitzer wrote:
> But sure, I suppose there is something I missed when refactoring Ming's
> change to get it acceptable for upstream. I went over the mechanical
> nature of what I did many times (comparing Ming's v4 to my v5).
And yes there is one subtl
Hi Mike,
On Wed, Jan 17, 2018 at 11:25:57AM -0500, Mike Snitzer wrote:
> From: Ming Lei
>
> blk_insert_cloned_request() is called in the fast path of a dm-rq driver
> (e.g. blk-mq request-based DM mpath). blk_insert_cloned_request() uses
> blk_mq_request_bypass_insert() to directly append the r
BLK_STS_RESOURCE can be returned from driver when any resource
is running out of. And the resource may not be related with tags,
such as kmalloc(GFP_ATOMIC), when queue is idle under this kind of
BLK_STS_RESOURCE, restart can't work any more, then IO hang may
be caused.
Most of drivers may call km
On Wed, Jan 17 2018 at 6:53pm -0500,
Bart Van Assche wrote:
> On Wed, 2018-01-17 at 18:43 -0500, Laurence Oberman wrote:
> > On Wed, 2018-01-17 at 23:31 +, Bart Van Assche wrote:
> > > On Wed, 2018-01-17 at 11:58 -0500, Mike Snitzer wrote:
> > > > On Wed, Jan 17 2018 at 11:50am -0500,
> > >
On Wed, 2018-01-17 at 23:53 +, Bart Van Assche wrote:
> On Wed, 2018-01-17 at 18:43 -0500, Laurence Oberman wrote:
> > On Wed, 2018-01-17 at 23:31 +, Bart Van Assche wrote:
> > > On Wed, 2018-01-17 at 11:58 -0500, Mike Snitzer wrote:
> > > > On Wed, Jan 17 2018 at 11:50am -0500,
> > > > Jen
On Wed, 2018-01-17 at 18:43 -0500, Laurence Oberman wrote:
> On Wed, 2018-01-17 at 23:31 +, Bart Van Assche wrote:
> > On Wed, 2018-01-17 at 11:58 -0500, Mike Snitzer wrote:
> > > On Wed, Jan 17 2018 at 11:50am -0500,
> > > Jens Axboe wrote:
> > >
> > > > On 1/17/18 9:25 AM, Mike Snitzer wrot
On Wed, 2018-01-17 at 23:31 +, Bart Van Assche wrote:
> On Wed, 2018-01-17 at 11:58 -0500, Mike Snitzer wrote:
> > On Wed, Jan 17 2018 at 11:50am -0500,
> > Jens Axboe wrote:
> >
> > > On 1/17/18 9:25 AM, Mike Snitzer wrote:
> > > > Hi Jens,
> > > >
> > > > Think this finally takes care of i
On Wed, 2018-01-17 at 11:58 -0500, Mike Snitzer wrote:
> On Wed, Jan 17 2018 at 11:50am -0500,
> Jens Axboe wrote:
>
> > On 1/17/18 9:25 AM, Mike Snitzer wrote:
> > > Hi Jens,
> > >
> > > Think this finally takes care of it! ;)
> > >
> > > Thanks,
> > > Mike
> > >
> > > Mike Snitzer (2):
> > >
On Wed, Jan 17, 2018 at 10:49:24AM +0800, Ming Lei wrote:
> Userfaultfd might be another choice:
>
> 1) map the block LBA space into a range of process vm space
That would limit the size of a block device to ~200TB (with my laptop's
CPU). That's probably OK for most users, but I suspect there ar
Hi Jens,
below are the two fixes for the new SGL support in 4.15 as a patch
series due to the issues with the git server.
On 1/17/18 2:04 PM, Christoph Hellwig wrote:
> Hi Jens,
>
> below are the two fixes for the new SGL support in 4.15 as a patch
> series due to the issues with the git server.
Applied, thanks.
--
Jens Axboe
Some iommu implementations can merge physically and/or virtually
contiguous segments inside sg_map_dma. The NVMe SGL support does not take
this into account and will warn because of falling off a loop. Pass the
number of mapped segments to nvme_pci_setup_sgls so that the SGL setup
can take the nu
From: Keith Busch
The driver needs to verify there is a payload with a command before
seeing if it should use SGLs to map it.
Fixes: 955b1b5a00ba ("nvme-pci: move use_sgl initialization to nvme_init_iod()")
Reported-by: Paul Menzel
Reviewed-by: Paul Menzel
Signed-off-by: Keith Busch
Signed-of
On Wed, Jan 17, 2018 at 01:30:44PM -0700, Jens Axboe wrote:
> On 1/17/18 11:36 AM, Christoph Hellwig wrote:
> > Hi Jens,
> >
> > two more last minute fixes for regressions due to the SGL support that
> > is new in Linux 4.15.
> >
> > The following changes since commit 32835a074171e7b83c1cefbbf9d6
On 1/17/18 11:36 AM, Christoph Hellwig wrote:
> Hi Jens,
>
> two more last minute fixes for regressions due to the SGL support that
> is new in Linux 4.15.
>
> The following changes since commit 32835a074171e7b83c1cefbbf9d681bb9518bbd5:
>
> Merge branch 'nvme-4.15' of git://git.infradead.org/n
The __blk_mq_register_dev(), blk_mq_unregister_dev(),
elv_register_queue() and elv_unregister_queue() calls need to be
protected with sysfs_lock but other code in these functions not.
Hence protect only this code with sysfs_lock. This patch fixes a
locking inversion issue in blk_unregister_queue()
Hello Jens,
The three patches in this series are what I came up with after having
analyzed a lockdep complaint triggered by blk_unregister_queue(). Please
consider these patches for kernel v4.16.
Thanks,
Bart.
Changes compared to v1:
- Restored the code that protects against races between chang
This patch does not change any functionality.
Signed-off-by: Bart Van Assche
---
block/elevator.c | 8
1 file changed, 8 insertions(+)
diff --git a/block/elevator.c b/block/elevator.c
index 4f00b53cd5fd..e87e9b43aba0 100644
--- a/block/elevator.c
+++ b/block/elevator.c
@@ -869,6 +869,8
These two functions are only called from inside the block layer so
unexport them.
Signed-off-by: Bart Van Assche
---
block/blk.h | 3 +++
block/elevator.c | 2 --
include/linux/elevator.h | 2 --
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/block/blk.h b/bl
Hello all,
We are getting the following on 4.14.13:
[33418.520838] bi_status >= ARRAY_SIZE(blk_errors): bi_status=201
The line above is our debug output showing the value of "idx" in
block/blk-core.c:174 blk_status_to_errno where the WARN_ON is located.
Why would bi_status have a value of 201?
Hi Jens,
two more last minute fixes for regressions due to the SGL support that
is new in Linux 4.15.
The following changes since commit 32835a074171e7b83c1cefbbf9d681bb9518bbd5:
Merge branch 'nvme-4.15' of git://git.infradead.org/nvme into for-linus
(2018-01-12 10:42:36 -0700)
are available
We are pleased to announce that the Call for Participation [1] for the
2018 USENIX Research in Linux File and Storage Technologies Summit (Linux
FAST Summit '18) [2] is now available. Linux FAST Summit '18 will take
place at the Oakland Marriott City Center on February 15 and will be
co-located wi
On Wed, 2018-01-17 at 21:04 +0800, Ming Lei wrote:
> On Wed, Jan 17, 2018 at 10:17 AM, Bart Van Assche
> wrote:
> > Sorry but I think what you wrote is wrong. kobject_del(&q->kobj) waits
> > until all
> > ongoing sysfs callback methods, including elv_iosched_store(), have
> > finished and
> > pr
On 1/16/18 11:31 AM, Bart Van Assche wrote:
> Fixes: 4246a0b63bd8 ("block: add a bi_error field to struct bio")
> Signed-off-by: Bart Van Assche
Applied, thanks.
--
Jens Axboe
On Wed, Jan 17 2018 at 11:50am -0500,
Jens Axboe wrote:
> On 1/17/18 9:25 AM, Mike Snitzer wrote:
> > Hi Jens,
> >
> > Think this finally takes care of it! ;)
> >
> > Thanks,
> > Mike
> >
> > Mike Snitzer (2):
> > blk-mq: factor out a few helpers from __blk_mq_try_issue_directly
> > blk-mq
On 1/17/18 9:25 AM, Mike Snitzer wrote:
> Hi Jens,
>
> Think this finally takes care of it! ;)
>
> Thanks,
> Mike
>
> Mike Snitzer (2):
> blk-mq: factor out a few helpers from __blk_mq_try_issue_directly
> blk-mq-sched: remove unused 'can_block' arg from blk_mq_sched_insert_request
>
> Ming
On 1/17/18 9:41 AM, Ming Lei wrote:
> Hi Jens,
>
> The 1st one fixes one regression caused by 20e4d81393 ("blk-mq: simplify
> queue mapping & schedule with each possisble CPU").
>
> The 2nd one add comments for current two races, and convert the WARN_ON
> into printk(KERN_WARN) with dump_stack()
Hi Jens,
The 1st one fixes one regression caused by 20e4d81393 ("blk-mq: simplify
queue mapping & schedule with each possisble CPU").
The 2nd one add comments for current two races, and convert the WARN_ON
into printk(KERN_WARN) with dump_stack() since this warning is harmless.
V2:
- fix
We know this WARN_ON is harmless and in reality it may be trigged,
so convert it to printk() and dump_stack() for avoiding to confuse
people.
Also add comment about two releated races here.
Cc: Christian Borntraeger
Cc: Stefan Haberland
Cc: Christoph Hellwig
Cc: Thomas Gleixner
Cc: "jianchao.
When hctx->next_cpu is set from possible online CPUs, there is one
race in which hctx->next_cpu may be set as >= nr_cpu_ids, and finally
break workqueue.
The race can be triggered in the following two sitations:
1) when one CPU is becoming DEAD, blk_mq_hctx_notify_dead() is called
to dispatch req
From: Ming Lei
blk_insert_cloned_request() is called in the fast path of a dm-rq driver
(e.g. blk-mq request-based DM mpath). blk_insert_cloned_request() uses
blk_mq_request_bypass_insert() to directly append the request to the
blk-mq hctx->dispatch_list of the underlying queue.
1) This way isn
Signed-off-by: Mike Snitzer
---
block/blk-exec.c | 2 +-
block/blk-mq-sched.c | 2 +-
block/blk-mq-sched.h | 2 +-
block/blk-mq.c | 16 +++-
4 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/block/blk-exec.c b/block/blk-exec.c
index 5c0f3dc446dc..f7b292f124
No functional change. Just makes code flow more logically.
In following commit, __blk_mq_try_issue_directly() will be used to
return the dispatch result (blk_status_t) to DM. DM needs this
information to improve IO merging.
Signed-off-by: Mike Snitzer
---
block/blk-mq.c | 79 +
Hi Jens,
Think this finally takes care of it! ;)
Thanks,
Mike
Mike Snitzer (2):
blk-mq: factor out a few helpers from __blk_mq_try_issue_directly
blk-mq-sched: remove unused 'can_block' arg from blk_mq_sched_insert_request
Ming Lei (1):
blk-mq: improve DM's blk-mq IO merging via blk_inser
On Wed, Jan 17, 2018 at 08:46:40AM -0700, Jens Axboe wrote:
> On 1/17/18 5:34 AM, Ming Lei wrote:
> > We know this WARN_ON is harmless and the stack trace isn't useful too,
> > so convert it to printk(), and avoid to confuse people.
>
> I disagree, it is useful to know the exact path it happened f
On Wed, Jan 17, 2018 at 08:45:44AM -0700, Jens Axboe wrote:
> On 1/17/18 5:34 AM, Ming Lei wrote:
> > When hctx->next_cpu is set from possible online CPUs, there is one
> > race in which hctx->next_cpu may be set as >= nr_cpu_ids, and finally
> > break workqueue.
> >
> > The race is triggered when
On 1/17/18 9:05 AM, Christian Borntraeger wrote:
>
>
> On 01/17/2018 04:46 PM, Jens Axboe wrote:
>> On 1/17/18 5:34 AM, Ming Lei wrote:
>>> We know this WARN_ON is harmless and the stack trace isn't useful too,
>>> so convert it to printk(), and avoid to confuse people.
>>
>> I disagree, it is us
On 01/17/2018 04:46 PM, Jens Axboe wrote:
> On 1/17/18 5:34 AM, Ming Lei wrote:
>> We know this WARN_ON is harmless and the stack trace isn't useful too,
>> so convert it to printk(), and avoid to confuse people.
>
> I disagree, it is useful to know the exact path it happened from,
> in case it'
On 1/17/18 5:34 AM, Ming Lei wrote:
> We know this WARN_ON is harmless and the stack trace isn't useful too,
> so convert it to printk(), and avoid to confuse people.
I disagree, it is useful to know the exact path it happened from,
in case it's a valid warning. It could be an inline run and
we sc
On 1/17/18 5:34 AM, Ming Lei wrote:
> When hctx->next_cpu is set from possible online CPUs, there is one
> race in which hctx->next_cpu may be set as >= nr_cpu_ids, and finally
> break workqueue.
>
> The race is triggered when one CPU is becoming DEAD, blk_mq_hctx_notify_dead()
> is called to disp
On 1/16/18 9:33 PM, Mike Snitzer wrote:
> From: Ming Lei
>
> blk_insert_cloned_request() is called in the fast path of a dm-rq driver
> (e.g. blk-mq request-based DM mpath). blk_insert_cloned_request() uses
> blk_mq_request_bypass_insert() to directly append the request to the
> blk-mq hctx->dis
On 17/01/2018 2:09 PM, tang.jun...@zte.com.cn wrote:
> From: Tang Junhui
>
> Hello Coly:
>
> Then in bch_count_io_errors(), why did us still keep these code:
>> 92 unsigned errors = atomic_add_return(1 << IO_ERROR_SHIFT,
>> 93 &ca->io_e
On Wed, Jan 17, 2018 at 10:17 AM, Bart Van Assche
wrote:
> On Wed, 2018-01-17 at 09:23 +0800, Ming Lei wrote:
>> On Wed, Jan 17, 2018 at 8:03 AM, Bart Van Assche
>> wrote:
>> > On Tue, 2018-01-16 at 17:32 -0500, Mike Snitzer wrote:
>> > > Therefore it seems to me that all queue_attr_{show,store}
We know this WARN_ON is harmless and the stack trace isn't useful too,
so convert it to printk(), and avoid to confuse people.
Also add comment about two releated races here.
Cc: Christian Borntraeger
Cc: Stefan Haberland
Cc: Christoph Hellwig
Cc: Thomas Gleixner
Cc: "jianchao.wang"
Signed-o
When hctx->next_cpu is set from possible online CPUs, there is one
race in which hctx->next_cpu may be set as >= nr_cpu_ids, and finally
break workqueue.
The race is triggered when one CPU is becoming DEAD, blk_mq_hctx_notify_dead()
is called to dispatch requests from the DEAD cpu context, but at
Hi Jens,
The 1st one fixes one regression caused by 20e4d81393 ("blk-mq: simplify
queue mapping & schedule with each possisble CPU").
The 2nd one add commens about current race, and convert the WARN_ON
into printk(KERN_WARN) since this warning is harmless.
Thanks,
Ming Lei (2):
blk-mq: make s
On Wed, Jan 17, 2018 at 11:07:48AM +0100, Christian Borntraeger wrote:
>
>
> On 01/17/2018 10:57 AM, Ming Lei wrote:
> > Hi Jianchao,
> >
> > On Wed, Jan 17, 2018 at 04:09:11PM +0800, jianchao.wang wrote:
> >> Hi ming
> >>
> >> Thanks for your kindly response.
> >>
> >> On 01/17/2018 02:22 PM,
On 01/17/2018 11:07 AM, Christian Borntraeger wrote:
>
>
> On 01/17/2018 10:57 AM, Ming Lei wrote:
>> Hi Jianchao,
>>
>> On Wed, Jan 17, 2018 at 04:09:11PM +0800, jianchao.wang wrote:
>>> Hi ming
>>>
>>> Thanks for your kindly response.
>>>
>>> On 01/17/2018 02:22 PM, Ming Lei wrote:
This
On 01/17/2018 10:57 AM, Ming Lei wrote:
> Hi Jianchao,
>
> On Wed, Jan 17, 2018 at 04:09:11PM +0800, jianchao.wang wrote:
>> Hi ming
>>
>> Thanks for your kindly response.
>>
>> On 01/17/2018 02:22 PM, Ming Lei wrote:
>>> This warning can't be removed completely, for example, the CPU figured
>>
Hi Jianchao,
On Wed, Jan 17, 2018 at 04:09:11PM +0800, jianchao.wang wrote:
> Hi ming
>
> Thanks for your kindly response.
>
> On 01/17/2018 02:22 PM, Ming Lei wrote:
> > This warning can't be removed completely, for example, the CPU figured
> > in blk_mq_hctx_next_cpu(hctx) can be put on again
Hi ming
Thanks for your kindly response.
On 01/17/2018 02:22 PM, Ming Lei wrote:
> This warning can't be removed completely, for example, the CPU figured
> in blk_mq_hctx_next_cpu(hctx) can be put on again just after the
> following call returns and before __blk_mq_run_hw_queue() is scheduled
>
> On 16 Jan 2018, at 22.10, SF Markus Elfring
> wrote:
>
> From: Markus Elfring
> Date: Tue, 16 Jan 2018 22:00:15 +0100
>
> Omit an extra message for a memory allocation failure in this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
62 matches
Mail list logo
