Hi Robert,
On Sun, Jul 13, 2014 at 05:15:15PM +, Elliott, Robert (Server Storage)
wrote:
> > > I will see if that solves the problem with the scsi-mq-3 tree, or
> > > at least some of the bisect trees leading up to it.
> >
> > scsi-mq-3 is still going after 45 minutes. I'll leave it running
On 7/8/2014 5:48 PM, Christoph Hellwig wrote:
I've pushed out a new scsi-mq.3 branch, which has been rebased on the
latest core-for-3.17 tree + the "RFC: clean up command setup" series
from June 29th. Robert Elliot found a problem with not fully zeroed
out UNMAP CDBs, which is fixed by the sane
lb...@interlog.com;
> James Bottomley; Bart Van Assche; linux-s...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: RE: scsi-mq V2
>
> > I will see if that solves the problem with the scsi-mq-3 tree, or
> > at least some of the bisect trees leading up to it.
>
> I will see if that solves the problem with the scsi-mq-3 tree, or
> at least some of the bisect trees leading up to it.
scsi-mq-3 is still going after 45 minutes. I'll leave it running
overnight.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: Re: scsi-mq V2
...
> Can you try the below totally untested patch instead? It looks like
> put_reqs_available() is not irq-safe.
>
With that addition alone, fio still runs into the same problem.
I added the same fix to get_re
On Fri, Jul 11, 2014 at 02:33:12PM +, Elliott, Robert (Server Storage)
wrote:
> That ran 9 total hours with no problem.
>
> Rather than revert in the bisect trees, I added just this single additional
> patch to the no-rebase tree, and the problem appeared:
Can you try the below totally untes
n LaHaise; linux-s...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: scsi-mq V2
>
> On Fri, Jul 11, 2014 at 06:02:03AM +, Elliott, Robert (Server Storage)
> wrote:
> > Allowing longer run times before declaring success, the problem
> > does appea
On Fri, Jul 11, 2014 at 06:02:03AM +, Elliott, Robert (Server Storage)
wrote:
> Allowing longer run times before declaring success, the problem
> does appear in all of the bisect trees. I just let fio
> continue to run for many minutes - no ^Cs necessary.
>
> no-rebase: good for > 45 minute
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Elliott, Robert (Server Storage)
>
> I added some prints in aio_setup_ring and ioctx_alloc and
> rebooted. This time it took much longer to hit the problem. It
> sur
..@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: Re: scsi-mq V2
>
> "Elliott, Robert (Server Storage)" writes:
>
> >> -Original Message-
> >> From: Christoph Hellwig [mailto:h...@infradead.org]
> >> Sent: Thursday, 10 July,
On 2014-07-10 22:05, Jeff Moyer wrote:
Jens Axboe writes:
On 2014-07-10 17:11, Jeff Moyer wrote:
Benjamin LaHaise writes:
[ 186.339064] ioctx_alloc: nr_events=-2 aio_max_nr=65536
[ 186.339065] ioctx_alloc: nr_events=-2 aio_max_nr=65536
[ 186.339067] ioctx_alloc: nr_events=-2 aio_max_nr
Jens Axboe writes:
> On 2014-07-10 17:11, Jeff Moyer wrote:
>> Benjamin LaHaise writes:
>>
[ 186.339064] ioctx_alloc: nr_events=-2 aio_max_nr=65536
[ 186.339065] ioctx_alloc: nr_events=-2 aio_max_nr=65536
[ 186.339067] ioctx_alloc: nr_events=-2 aio_max_nr=65536
[ 186
On 2014-07-10 17:11, Jeff Moyer wrote:
Benjamin LaHaise writes:
[ 186.339064] ioctx_alloc: nr_events=-2 aio_max_nr=65536
[ 186.339065] ioctx_alloc: nr_events=-2 aio_max_nr=65536
[ 186.339067] ioctx_alloc: nr_events=-2 aio_max_nr=65536
[ 186.339068] ioctx_alloc: nr_events=-2 aio_max_nr=655
Jeff Moyer writes:
> Hi, Rob,
>
> Can you get sysrq-t output for me? I don't know how/why we'd continue
> to get io_submits for an exiting process.
Also, do you know what sys_io_submit is returning?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
og.com; James Bottomley; Bart Van Assche;
>> Benjamin LaHaise; linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org
>> Subject: Re: scsi-mq V2
>>
>> On Thu, Jul 10, 2014 at 09:04:22AM -0700, Christoph Hellwig wrote:
>> > It's starting to look weird. I'll prepare
.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: scsi-mq V2
>
> On Thu, Jul 10, 2014 at 09:04:22AM -0700, Christoph Hellwig wrote:
> > It's starting to look weird. I'll prepare another two bisect branches
> > around some MM changes, which seems the only other p
On Thu, Jul 10, 2014 at 09:04:22AM -0700, Christoph Hellwig wrote:
> It's starting to look weird. I'll prepare another two bisect branches
> around some MM changes, which seems the only other possible candidate.
I've pushed out scsi-mq.3-bisect-3 and scsi-mq.3-bisect-4 for you.
--
To unsubscribe
On Thu, Jul 10, 2014 at 03:51:44PM +, Elliott, Robert (Server Storage)
wrote:
> > scsi-mq.3-bisect-1 branch that is rebased to just before the merge of
> > the block tree
>
> good.
>
> > and a scsi-mq.3-bisect-2 branch that is just after the merge of the
> > block tree to get started.
>
>
n LaHaise; linux-s...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: Re: scsi-mq V2
>
> On Thu, Jul 10, 2014 at 12:53:36AM +, Elliott, Robert (Server Storage)
> wrote:
> > the problem still occurs - fio results in low or 0 IOPS, with perf top
> > reporting unus
Benjamin LaHaise writes:
>>
>> [ 186.339064] ioctx_alloc: nr_events=-2 aio_max_nr=65536
>> [ 186.339065] ioctx_alloc: nr_events=-2 aio_max_nr=65536
>> [ 186.339067] ioctx_alloc: nr_events=-2 aio_max_nr=65536
>> [ 186.339068] ioctx_alloc: nr_events=-2 aio_max_nr=65536
>> [ 186.339069] ioctx_
Cc: Elliott, Robert (Server Storage); dgilb...@interlog.com; James
> > Bottomley;
> > Bart Van Assche; linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org
> > Subject: Re: scsi-mq V2
> >
> > On 2014-07-10 15:50, Christoph Hellwig wrote:
> > > On Thu, Ju
.org; linux-kernel@vger.kernel.org
> Subject: Re: scsi-mq V2
>
> On 2014-07-10 15:50, Christoph Hellwig wrote:
> > On Thu, Jul 10, 2014 at 09:36:09AM -0400, Benjamin LaHaise wrote:
> >> There is one possible concern that could be exacerbated by other changes
> in
> >&
On 2014-07-10 15:50, Christoph Hellwig wrote:
On Thu, Jul 10, 2014 at 09:36:09AM -0400, Benjamin LaHaise wrote:
There is one possible concern that could be exacerbated by other changes in
the system: if the application is running close to the bare minimum number
of requests allocated in io_setup
On 2014-07-10 15:50, Benjamin LaHaise wrote:
On Thu, Jul 10, 2014 at 03:48:10PM +0200, Jens Axboe wrote:
On 2014-07-10 15:44, Benjamin LaHaise wrote:
On Thu, Jul 10, 2014 at 03:39:57PM +0200, Jens Axboe wrote:
That's how fio always runs, it sets up the context with the exact queue
depth that i
On Thu, Jul 10, 2014 at 03:48:10PM +0200, Jens Axboe wrote:
> On 2014-07-10 15:44, Benjamin LaHaise wrote:
> >On Thu, Jul 10, 2014 at 03:39:57PM +0200, Jens Axboe wrote:
> >>That's how fio always runs, it sets up the context with the exact queue
> >>depth that it needs. Do we have a good enough und
On Thu, Jul 10, 2014 at 09:36:09AM -0400, Benjamin LaHaise wrote:
> There is one possible concern that could be exacerbated by other changes in
> the system: if the application is running close to the bare minimum number
> of requests allocated in io_setup(), the per cpu reference counters will
On 2014-07-10 15:44, Benjamin LaHaise wrote:
On Thu, Jul 10, 2014 at 03:39:57PM +0200, Jens Axboe wrote:
That's how fio always runs, it sets up the context with the exact queue
depth that it needs. Do we have a good enough understanding of other aio
use cases to say that this isn't the norm? I w
On Thu, Jul 10, 2014 at 03:39:57PM +0200, Jens Axboe wrote:
> That's how fio always runs, it sets up the context with the exact queue
> depth that it needs. Do we have a good enough understanding of other aio
> use cases to say that this isn't the norm? I would expect it to be, it's
> the way th
On 2014-07-10 15:36, Benjamin LaHaise wrote:
On Wed, Jul 09, 2014 at 11:20:40PM -0700, Christoph Hellwig wrote:
On Thu, Jul 10, 2014 at 12:53:36AM +, Elliott, Robert (Server Storage)
wrote:
the problem still occurs - fio results in low or 0 IOPS, with perf top
reporting unusual amounts of
On Wed, Jul 09, 2014 at 11:20:40PM -0700, Christoph Hellwig wrote:
> On Thu, Jul 10, 2014 at 12:53:36AM +, Elliott, Robert (Server Storage)
> wrote:
> > the problem still occurs - fio results in low or 0 IOPS, with perf top
> > reporting unusual amounts of time spent in do_io_submit and io_su
On Thu, Jul 10, 2014 at 12:53:36AM +, Elliott, Robert (Server Storage)
wrote:
> the problem still occurs - fio results in low or 0 IOPS, with perf top
> reporting unusual amounts of time spent in do_io_submit and io_submit.
The diff between the two version doesn't show too much other possibl
..@vger.kernel.org
> Subject: Re: scsi-mq V2
>
> On 2014-07-09 18:39, Douglas Gilbert wrote:
> > On 14-07-08 10:48 AM, Christoph Hellwig wrote:
> >> On Wed, Jun 25, 2014 at 06:51:47PM +0200, Christoph Hellwig wrote:
> >>> Changes from V1:
> >>>
On 2014-07-09 18:39, Douglas Gilbert wrote:
On 14-07-08 10:48 AM, Christoph Hellwig wrote:
On Wed, Jun 25, 2014 at 06:51:47PM +0200, Christoph Hellwig wrote:
Changes from V1:
- rebased on top of the core-for-3.17 branch, most notable the
scsi logging changes
- fixed handling of cmd_list
On 14-07-08 10:48 AM, Christoph Hellwig wrote:
On Wed, Jun 25, 2014 at 06:51:47PM +0200, Christoph Hellwig wrote:
Changes from V1:
- rebased on top of the core-for-3.17 branch, most notable the
scsi logging changes
- fixed handling of cmd_list to prevent crashes for some heavy
worklo
On Wed, Jun 25, 2014 at 06:51:47PM +0200, Christoph Hellwig wrote:
> Changes from V1:
> - rebased on top of the core-for-3.17 branch, most notable the
>scsi logging changes
> - fixed handling of cmd_list to prevent crashes for some heavy
>workloads
> - fixed incorrect handling of !target
> "Christoph" == Christoph Hellwig writes:
Christoph> I'm still looking for one (or better two) persons familar
Christoph> with the SCSI and/or block code to go over it and do a real
Christoph> detailed review.
I'm on vacation for a couple of days. Will review Wednesday.
--
Martin K. Peter
On Mon, Jun 30, 2014 at 09:20:51AM -0600, Jens Axboe wrote:
> Ran stress testing from Friday to now, 65h of beating up on it and no
> problems observed. 47TB read and 20TB written for a total of 17.7
> billion of IOs issued and completed. Latencies look good. I officially
> declare this code for bu
On 06/25/2014 10:50 PM, Jens Axboe wrote:
> On 2014-06-25 10:51, Christoph Hellwig wrote:
>> This is the second post of the scsi-mq series.
>>
>> At this point the code is ready for merging and use by developers and
>> early
>> adopters. The core blk-mq code isn't that suitable for slow devices
>>
(Server Storage); linux-
>> s...@vger.kernel.org; linux-kernel@vger.kernel.org
>> Subject: Re: scsi-mq V2
>>
>> On 2014-06-25 10:51, Christoph Hellwig wrote:
>>> This is the second post of the scsi-mq series.
>>>
> ...
>>>
>>> Changes from
> -Original Message-
> From: Jens Axboe [mailto:ax...@kernel.dk]
> Sent: Wednesday, 25 June, 2014 11:51 PM
> To: Christoph Hellwig; James Bottomley
> Cc: Bart Van Assche; Elliott, Robert (Server Storage); linux-
> s...@vger.kernel.org; linux-kernel@vger.kernel.org
>
On 2014-06-25 10:51, Christoph Hellwig wrote:
This is the second post of the scsi-mq series.
At this point the code is ready for merging and use by developers and early
adopters. The core blk-mq code isn't that suitable for slow devices
yet, mostly due to the lack of an I/O scheduler, but Jens
On Sat, Jun 21, 2014 at 12:52:22AM +, Elliott, Robert (Server Storage)
wrote:
> Some of those context switches might be from scsi_end_request(),
> which always schedules the scsi_requeue_run_queue() function via the
> requeue_work workqueue for scsi-mq. That causes lots of context
> switche
> -Original Message-
> From: Bart Van Assche [mailto:bvanass...@acm.org]
> Sent: Wednesday, 18 June, 2014 2:09 AM
> To: Jens Axboe; Christoph Hellwig; James Bottomley
> Cc: Elliott, Robert (Server Storage); linux-s...@vger.kernel.org; linux-
> ker...@vger.kernel.org
&
el@vger.kernel.org
> Subject: Re: scsi-mq
>
> On 2014-06-17 07:27, Bart Van Assche wrote:
> > On 06/12/14 15:48, Christoph Hellwig wrote:
> >> Bart and Robert have helped with some very detailed measurements that they
> >> might be able to send in reply to this, although th
On 06/18/14 05:44, Jens Axboe wrote:
> Thanks for posting these numbers, Bart. The CPU utilization and IOPS
> speak a very clear message. The only mystery is why the singe threaded
> performance is down. That we need to get sort, but it's not a show
> stopper for inclusion.
>
> If you run the sing
On 2014-06-17 07:27, Bart Van Assche wrote:
On 06/12/14 15:48, Christoph Hellwig wrote:
Bart and Robert have helped with some very detailed measurements that they
might be able to send in reply to this, although these usually involve
significantly reworked low level drivers to avoid other bottle
On 06/12/14 15:48, Christoph Hellwig wrote:
> Bart and Robert have helped with some very detailed measurements that they
> might be able to send in reply to this, although these usually involve
> significantly reworked low level drivers to avoid other bottle necks.
In case someone would like to se
On 06/12/14 15:48, Christoph Hellwig wrote:
> The usage of blk-mq dramatically decreases CPU usage under all workloads going
> down from 100% CPU usage that the old setup can hit easily to usually less
> than 20% for maxing out storage subsystems with 512 byte reads and writes,
> and it allows to e
On Mon, 2013-12-23 at 11:16 +0800, Fengguang Wu wrote:
> Greetings,
>
> I got the below dmesg and the first bad commit is
>
> commit 29ff818720ce09b044652b83e9c70ef474800d54
> Author: Nicholas Bellinger
> AuthorDate: Thu May 23 22:11:38 2013 -0700
> Commit: Nicholas Bellinger
> CommitDa
Hi Jianpeng,
(Trimming CC's)
On Wed, 2013-11-27 at 10:46 +0800, kedacomkernel wrote:
> Hi all，
> I used target-pending/scsi-mq to test intel ahci，but it can't work.I
> modify some places, now it can work.But still met hung task or oops.
So after looking at your patches sent offlist, I don'
Hi all，
I used target-pending/scsi-mq to test intel ahci，but it can't work.I
modify some places, now it can work.But still met hung task or oops.
Who can receive my patch for that?
Thanks!
Jianpeng Ma
>On Sat, 2013-11-02 at 16:10 +, Jayamohan Kallickal wrote:
>
>
>
>> >> On a related
On Sat, 2013-11-02 at 16:10 +, Jayamohan Kallickal wrote:
> >> On a related note, some iscsi vendor has been hitting a crash with
> >> your tree.
>
> >I got an email from Jayamohan recently, but the OOPs did not appear to be
> >scsi-mq related..
>
> I do see the crash on my Ubuntu VM run
-Original Message-
From: open-is...@googlegroups.com [mailto:open-is...@googlegroups.com] On
Behalf Of Nicholas A. Bellinger
Sent: Friday, November 01, 2013 1:37 PM
To: Mike Christie
Cc: open-is...@googlegroups.com; linux-scsi; LKML; target-devel; Or Gerlitz
Subject: Re: scsi-mq + open
On Fri, 2013-11-01 at 09:46 -0500, Mike Christie wrote:
> On 10/28/13 5:03 PM, Nicholas A. Bellinger wrote:
> > Hi Mike,
> >
> > Just curious as to the status of the scsi-mq conversion patches for
> > open-iscsi that you where working on a while back..?
> >
> > I'm asking because recently I've been
On 10/28/13 5:03 PM, Nicholas A. Bellinger wrote:
Hi Mike,
Just curious as to the status of the scsi-mq conversion patches for
open-iscsi that you where working on a while back..?
I'm asking because recently I've been spending alot of time with scsi-mq
+ virtio-scsi, and would really to start b
On 10/11/2013 06:19 AM, Christoph Hellwig wrote:
> On Thu, Oct 10, 2013 at 09:32:41PM +0200, Alexander Gordeev wrote:
>> I wonder, if blk-mq- prefix should remain?.. This s code seems pretty much
>> generic to me.
>
> Seems like nowdays you should just use the percpu-ida allocator directly,
> Shao
On Thu, Oct 10, 2013 at 09:32:41PM +0200, Alexander Gordeev wrote:
> I wonder, if blk-mq- prefix should remain?.. This s code seems pretty much
> generic to me.
Seems like nowdays you should just use the percpu-ida allocator directly,
Shaohua Li hast just sent patches to switch blk-mq over to it a
On Thu, Oct 10, 2013 at 09:17:14PM +0200, Christoph Hellwig wrote:
> > What is the criteria for patches to include in your tree? I would suggest
> > to consider this one https://lkml.org/lkml/2013/8/9/90 if it fits.
>
> For this one you probably want to send a patch to Jens to move blk-mq-tag.h
>
> What is the criteria for patches to include in your tree? I would suggest
> to consider this one https://lkml.org/lkml/2013/8/9/90 if it fits.
For this one you probably want to send a patch to Jens to move blk-mq-tag.h
to include/linux first instead of doing the relative include hack.
Also the
On Wed, 2013-10-09 at 21:46 +0200, Alexander Gordeev wrote:
> On Wed, Oct 09, 2013 at 12:12:51PM -0700, Nicholas A. Bellinger wrote:
> > Just a heads up that the scsi-mq alpha branch has been updated to Jen's
> > latest linux-block/new-queue containing hch's recent blk-mq
> > improvements, along wi
On Wed, Oct 09, 2013 at 12:12:51PM -0700, Nicholas A. Bellinger wrote:
> Just a heads up that the scsi-mq alpha branch has been updated to Jen's
> latest linux-block/new-queue containing hch's recent blk-mq
> improvements, along with Alexander's patch for the is_flush_fua +
> queue_depth=1 bug.
O
61 matches
Mail list logo
