From: Jens Axboe <axboe@suse.de>
To: Avi Kivity <avi@argo.co.il>
Cc: Mark Lord <lkml@rtr.ca>, Linus Torvalds <torvalds@osdl.org>,
Nick Piggin <nickpiggin@yahoo.com.au>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, mason@suse.com,
andrea@suse.de, hugh@veritas.com
Subject: Re: NCQ performance (was Re: [rfc][patch] remove racy sync_page?)
Date: Thu, 1 Jun 2006 20:04:05 +0200 [thread overview]
Message-ID: <20060601180405.GP4400@suse.de> (raw)
In-Reply-To: <20060601150320.GO4400@suse.de>
On Thu, Jun 01 2006, Jens Axboe wrote:
> On Thu, Jun 01 2006, Avi Kivity wrote:
> > Jens Axboe wrote:
> > >
> > >Ok, I decided to rerun a simple random read work load (with fio), using
> > >depths 1 and 32. The test is simple - it does random reads all over the
> > >drive size with 4kb block sizes. The reads are O_DIRECT. The test
> > >pattern was set to repeatable, so it's going through the same workload.
> > >The test spans the first 32G of the drive and runtime is capped at 20
> > >seconds.
> > >
> >
> > Did you modify the iodepth given to the test program, or to the drive?
> > If the former, then some of the performance increase came from the Linux
> > elevator.
> >
> > Ideally exactly the same test would be run with the just the drive
> > parameters changed.
>
> Just from the program. Since the software depth matched the software
> depth, I'd be surprised if it made much of a difference here. I can
> rerun the same test tomorrow with the drive depth modified the and
> software depth fixed at 32. Then the io scheduler can at least help the
> drive without NCQ out somewhat.
Same test, but with iodepth=48 for both ncq depth 1 and ncq depth 31.
This gives the io scheduler something to work with for both cases.
sda: Maxtor 7B300S0
sdb: Maxtor 7L320S0
sdc: SAMSUNG HD160JJ
sdd: HDS725050KLA360 (Hitachi 500GB drive)
drive depth KiB/sec diff diff 1/1
----------------------------------------------------------------
sda 1/1 397
sda 1 513 +29%
sda 31 673 +31+ +69%
sdb 1/1 397
sdb 1 535 +35%
sdb 31 741 +38% +87%
sdc 1/1 372
sdc 1 449 +21%
sdc 31 507 +13% +36%
sdd 1/1 489
sdd 1 650 +33%
sdd 31 941 +45% +92%
Conclusions: the io scheduler helps, NCQ help - both combined helps a
lot. The Samsung firmware looks bad. Additional requests in io scheduler
when using NCQ doesn't help, except for the new firmware Maxtor.
Suspect. NCQ still helps a lot, > 30% for all drives except the Samsung.
--
Jens Axboe
WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <axboe@suse.de>
To: Avi Kivity <avi@argo.co.il>
Cc: Mark Lord <lkml@rtr.ca>, Linus Torvalds <torvalds@osdl.org>,
Nick Piggin <nickpiggin@yahoo.com.au>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, mason@suse.com,
andrea@suse.de, hugh@veritas.com
Subject: Re: NCQ performance (was Re: [rfc][patch] remove racy sync_page?)
Date: Thu, 1 Jun 2006 20:04:05 +0200 [thread overview]
Message-ID: <20060601180405.GP4400@suse.de> (raw)
In-Reply-To: <20060601150320.GO4400@suse.de>
On Thu, Jun 01 2006, Jens Axboe wrote:
> On Thu, Jun 01 2006, Avi Kivity wrote:
> > Jens Axboe wrote:
> > >
> > >Ok, I decided to rerun a simple random read work load (with fio), using
> > >depths 1 and 32. The test is simple - it does random reads all over the
> > >drive size with 4kb block sizes. The reads are O_DIRECT. The test
> > >pattern was set to repeatable, so it's going through the same workload.
> > >The test spans the first 32G of the drive and runtime is capped at 20
> > >seconds.
> > >
> >
> > Did you modify the iodepth given to the test program, or to the drive?
> > If the former, then some of the performance increase came from the Linux
> > elevator.
> >
> > Ideally exactly the same test would be run with the just the drive
> > parameters changed.
>
> Just from the program. Since the software depth matched the software
> depth, I'd be surprised if it made much of a difference here. I can
> rerun the same test tomorrow with the drive depth modified the and
> software depth fixed at 32. Then the io scheduler can at least help the
> drive without NCQ out somewhat.
Same test, but with iodepth=48 for both ncq depth 1 and ncq depth 31.
This gives the io scheduler something to work with for both cases.
sda: Maxtor 7B300S0
sdb: Maxtor 7L320S0
sdc: SAMSUNG HD160JJ
sdd: HDS725050KLA360 (Hitachi 500GB drive)
drive depth KiB/sec diff diff 1/1
----------------------------------------------------------------
sda 1/1 397
sda 1 513 +29%
sda 31 673 +31+ +69%
sdb 1/1 397
sdb 1 535 +35%
sdb 31 741 +38% +87%
sdc 1/1 372
sdc 1 449 +21%
sdc 31 507 +13% +36%
sdd 1/1 489
sdd 1 650 +33%
sdd 31 941 +45% +92%
Conclusions: the io scheduler helps, NCQ help - both combined helps a
lot. The Samsung firmware looks bad. Additional requests in io scheduler
when using NCQ doesn't help, except for the new firmware Maxtor.
Suspect. NCQ still helps a lot, > 30% for all drives except the Samsung.
--
Jens Axboe
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2006-06-01 18:02 UTC|newest]
Thread overview: 118+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-29 9:34 [rfc][patch] remove racy sync_page? Nick Piggin
2006-05-29 19:15 ` Andrew Morton
2006-05-29 19:15 ` Andrew Morton
2006-05-30 0:08 ` Nick Piggin
2006-05-30 0:08 ` Nick Piggin
2006-05-30 1:32 ` Andrew Morton
2006-05-30 1:32 ` Andrew Morton
2006-05-30 2:54 ` Nick Piggin
2006-05-30 2:54 ` Nick Piggin
2006-05-30 3:14 ` Andrew Morton
2006-05-30 3:14 ` Andrew Morton
2006-05-30 4:13 ` Nick Piggin
2006-05-30 4:13 ` Nick Piggin
2006-05-30 9:05 ` Jens Axboe
2006-05-30 9:05 ` Jens Axboe
2006-05-31 13:43 ` Nick Piggin
2006-05-31 13:43 ` Nick Piggin
2006-05-31 15:09 ` Hugh Dickins
2006-05-31 15:09 ` Hugh Dickins
2006-05-31 15:22 ` Nick Piggin
2006-05-31 15:22 ` Nick Piggin
2006-05-31 17:51 ` Jens Axboe
2006-05-31 17:51 ` Jens Axboe
2006-05-31 17:50 ` Jens Axboe
2006-05-31 17:50 ` Jens Axboe
2006-05-30 4:20 ` Linus Torvalds
2006-05-30 4:20 ` Linus Torvalds
2006-05-30 5:07 ` Nick Piggin
2006-05-30 5:07 ` Nick Piggin
2006-05-30 5:21 ` Nick Piggin
2006-05-30 5:21 ` Nick Piggin
2006-05-30 6:12 ` Neil Brown
2006-05-30 6:12 ` Neil Brown
2006-05-30 7:10 ` Nick Piggin
2006-05-30 7:10 ` Nick Piggin
2006-05-31 4:34 ` Neil Brown
2006-05-31 4:34 ` Neil Brown
2006-05-30 8:24 ` Nikita Danilov
2006-05-30 8:24 ` Nikita Danilov
2006-05-30 17:55 ` Linus Torvalds
2006-05-30 17:55 ` Linus Torvalds
2006-05-31 0:32 ` Nick Piggin
2006-05-31 0:32 ` Nick Piggin
2006-05-31 0:56 ` Linus Torvalds
2006-05-31 0:56 ` Linus Torvalds
2006-05-31 1:33 ` Mark Lord
2006-05-31 1:33 ` Mark Lord
2006-05-31 6:11 ` Jens Axboe
2006-05-31 6:11 ` Jens Axboe
2006-05-31 12:55 ` Mark Lord
2006-05-31 12:55 ` Mark Lord
2006-05-31 13:02 ` Jens Axboe
2006-05-31 13:02 ` Jens Axboe
2006-06-01 13:19 ` NCQ performance (was Re: [rfc][patch] remove racy sync_page?) Jens Axboe
2006-06-01 13:19 ` Jens Axboe
2006-06-01 14:56 ` Avi Kivity
2006-06-01 14:56 ` Avi Kivity
2006-06-01 15:03 ` Jens Axboe
2006-06-01 15:03 ` Jens Axboe
2006-06-01 18:04 ` Jens Axboe [this message]
2006-06-01 18:04 ` Jens Axboe
2006-06-05 5:30 ` Avi Kivity
2006-06-05 5:30 ` Avi Kivity
2006-06-05 7:59 ` Jens Axboe
2006-06-05 7:59 ` Jens Axboe
2006-05-31 12:31 ` [rfc][patch] remove racy sync_page? Helge Hafting
2006-05-31 12:31 ` Helge Hafting
2006-05-31 12:36 ` Arjan van de Ven
2006-05-31 12:36 ` Arjan van de Ven
2006-05-31 13:29 ` Nick Piggin
2006-05-31 13:29 ` Nick Piggin
2006-05-31 13:41 ` Jens Axboe
2006-05-31 13:41 ` Jens Axboe
2006-05-31 13:54 ` Nick Piggin
2006-05-31 13:54 ` Nick Piggin
2006-05-31 14:43 ` Linus Torvalds
2006-05-31 14:43 ` Linus Torvalds
2006-05-31 14:57 ` Nick Piggin
2006-05-31 14:57 ` Nick Piggin
2006-05-31 15:13 ` Linus Torvalds
2006-05-31 15:13 ` Linus Torvalds
2006-05-31 15:33 ` Nick Piggin
2006-05-31 15:57 ` Linus Torvalds
2006-05-31 16:12 ` Linus Torvalds
2006-05-31 16:26 ` Nick Piggin
2006-05-31 16:19 ` Nick Piggin
2006-05-31 16:22 ` Nick Piggin
2006-05-31 16:41 ` Linus Torvalds
2006-06-02 2:34 ` Nick Piggin
2006-06-02 2:39 ` Nick Piggin
2006-05-31 16:39 ` Linus Torvalds
2006-06-02 2:21 ` Nick Piggin
2006-05-31 23:59 ` Neil Brown
2006-05-31 15:09 ` Linus Torvalds
2006-05-31 15:09 ` Linus Torvalds
2006-05-31 18:13 ` Jens Axboe
2006-05-31 18:13 ` Jens Axboe
2006-05-31 18:26 ` Linus Torvalds
2006-05-31 18:26 ` Linus Torvalds
2006-05-30 5:36 ` Nick Piggin
2006-05-30 18:31 ` Hugh Dickins
2006-05-30 18:31 ` Hugh Dickins
2006-05-31 0:21 ` Nick Piggin
2006-05-31 0:21 ` Nick Piggin
2006-05-31 3:06 ` Hugh Dickins
2006-05-31 3:06 ` Hugh Dickins
2006-05-31 14:30 ` Hugh Dickins
2006-05-31 14:30 ` Hugh Dickins
2006-05-31 17:56 ` Jens Axboe
2006-05-31 17:56 ` Jens Axboe
2006-05-30 5:51 ` Josef Sipek
2006-05-30 5:51 ` Josef Sipek
2006-05-30 6:44 ` Nick Piggin
2006-05-30 6:44 ` Nick Piggin
2006-05-30 6:50 ` Nick Piggin
2006-05-30 6:50 ` Nick Piggin
2006-05-30 13:12 ` Josef Sipek
2006-05-30 13:12 ` Josef Sipek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060601180405.GP4400@suse.de \
--to=axboe@suse.de \
--cc=andrea@suse.de \
--cc=avi@argo.co.il \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkml@rtr.ca \
--cc=mason@suse.com \
--cc=nickpiggin@yahoo.com.au \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.