On 8/21/2014 5:02 PM, Sagi Grimberg wrote:
On 8/21/2014 4:03 PM, Christoph Hellwig wrote:
On Thu, Aug 21, 2014 at 03:32:09PM +0300, Sagi Grimberg wrote:
So I just got back to checking this issue of *extremely low* IO write
performance I got in 3.16-rc2.
Please test with 3.16 final. There
On 8/21/2014 5:02 PM, Sagi Grimberg wrote:
On 8/21/2014 4:03 PM, Christoph Hellwig wrote:
On Thu, Aug 21, 2014 at 03:32:09PM +0300, Sagi Grimberg wrote:
So I just got back to checking this issue of *extremely low* IO write
performance I got in 3.16-rc2.
Please test with 3.16 final. There
On 8/21/2014 4:03 PM, Christoph Hellwig wrote:
On Thu, Aug 21, 2014 at 03:32:09PM +0300, Sagi Grimberg wrote:
So I just got back to checking this issue of *extremely low* IO write
performance I got in 3.16-rc2.
Please test with 3.16 final. There once issue each in aio and dio
that caused bad
On Thu, Aug 21, 2014 at 03:32:09PM +0300, Sagi Grimberg wrote:
> So I just got back to checking this issue of *extremely low* IO write
> performance I got in 3.16-rc2.
Please test with 3.16 final. There once issue each in aio and dio
that caused bad I/O performance regression that were only
On 7/14/2014 12:13 PM, Sagi Grimberg wrote:
I'd like to share some benchmarks I took on this patch set using iSER
initiator (+2 pre-submitted performance improvements) vs LIO iSER target.
I ran workloads I think are interesting use-cases (single LUN with 1,2,4
IO threads up to a fully
On 7/14/2014 12:13 PM, Sagi Grimberg wrote:
SNIP
I'd like to share some benchmarks I took on this patch set using iSER
initiator (+2 pre-submitted performance improvements) vs LIO iSER target.
I ran workloads I think are interesting use-cases (single LUN with 1,2,4
IO threads up to a fully
On Thu, Aug 21, 2014 at 03:32:09PM +0300, Sagi Grimberg wrote:
So I just got back to checking this issue of *extremely low* IO write
performance I got in 3.16-rc2.
Please test with 3.16 final. There once issue each in aio and dio
that caused bad I/O performance regression that were only fixed
On 8/21/2014 4:03 PM, Christoph Hellwig wrote:
On Thu, Aug 21, 2014 at 03:32:09PM +0300, Sagi Grimberg wrote:
So I just got back to checking this issue of *extremely low* IO write
performance I got in 3.16-rc2.
Please test with 3.16 final. There once issue each in aio and dio
that caused bad
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
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
On 7/8/2014 5:48 PM, Christoph Hellwig wrote:
SNIP
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
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
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.
>
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.
scsi-mq-3 is still going after 45 minutes. I'll leave
> 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
.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
...@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_reqs_available, which also accesses
kcpu
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 message
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
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
> -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
>
-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
survived
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 minutes (I
...@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 appear in all of the bisect trees. I just let fio
continue to run
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 untested
..@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
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
[
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
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
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 another tw
.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 possible ca
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
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]
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
> &g
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
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
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
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
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
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
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
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 possible
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_submit.
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 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 that
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
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
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: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
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
@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
the system: if the application is running close to the bare minimum
...@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, Jul 10, 2014 at 09:36:09AM -0400, Benjamin LaHaise wrote:
There is one possible concern that could
Benjamin LaHaise b...@kvack.org 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]
; 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 unusual amounts of time spent in do_io_submit and io_submit
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.
good.
It's
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
@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 possible candidate.
I've pushed out scsi-mq.3-bisect-3
Good
;
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 another two bisect branches
around some MM changes, which seems the only other possible
Jeff Moyer jmo...@redhat.com 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
On 2014-07-10 17:11, Jeff Moyer wrote:
Benjamin LaHaise b...@kvack.org 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
Jens Axboe ax...@kernel.dk writes:
On 2014-07-10 17:11, Jeff Moyer wrote:
Benjamin LaHaise b...@kvack.org 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
[
On 2014-07-10 22:05, Jeff Moyer wrote:
Jens Axboe ax...@kernel.dk writes:
On 2014-07-10 17:11, Jeff Moyer wrote:
Benjamin LaHaise b...@kvack.org 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]
-
ker...@vger.kernel.org
Subject: Re: scsi-mq V2
Elliott, Robert (Server Storage) elli...@hp.com writes:
-Original Message-
From: Christoph Hellwig [mailto:h...@infradead.org]
Sent: Thursday, 10 July, 2014 11:15 AM
To: Elliott, Robert (Server Storage)
Cc: Jens Axboe; dgilb
..@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
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
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
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
: 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:
- rebased on top of the core-for-3.17 branch, most notable the
scsi logging changes
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
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
> "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.
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
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
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
yet, mostly
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 bug
Christoph == Christoph Hellwig h...@infradead.org 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
(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
; 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 V1:
- rebased on top of the core-for-3.17 branch, most notable the
scsi logging changes
- fixed handling of cmd_list
> -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
>
-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
Subject: Re: scsi-mq V2
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
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 is working on it.
Similarly there is no
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 is working on it.
Similarly there is no
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
92 matches
Mail list logo