From: "zhao, forrest" <forrest.zhao@intel.com>
To: Tejun Heo <htejun@gmail.com>
Cc: linux-ide@vger.kernel.org
Subject: Re: A question about NCQ
Date: Wed, 17 May 2006 11:24:29 +0800 [thread overview]
Message-ID: <1147836269.7273.127.camel@forrest26.sh.intel.com> (raw)
In-Reply-To: <446A8C78.2000607@gmail.com>
On Wed, 2006-05-17 at 11:37 +0900, Tejun Heo wrote:
> zhao, forrest wrote:
> > On Tue, 2006-05-16 at 19:49 +0900, Tejun Heo wrote:
> >> I don't know the workload of iozone. But NCQ shines when there are many
> >> concurrent IOs in progress. A good real world example would be busy
> >> file-serving web server. It generally helps if there are multiple IO
> >> requests. If iozone is single-threaded (IO-wise), try to run multiple
> >> copies of them and compare the results.
> >>
> >> Also, you need to pay attention to IO schedule in use, IIRC as and cfq
> >> are heavily optimized for single-queued devices and might not show the
> >> best performance depending on workload. For functionality test, I
> >> usually use deadline. It's simpler and usually doesn't get in the way,
> >> which, BTW, may or may not translate into better performance.
> >>
> > Tejun,
> >
> > I run iozone with 8 concurrent threads. From my understanding, NCQ
> > should at least provide the same throughput as non-NCQ. But the attached
> > test result showed that NCQ has the lower throughput compared with non-
> > NCQ.
> >
> > The io scheduler is anticipatory.
> > The kernel without NCQ is 2.6.16-rc6, the kernel with NCQ is #upstream.
> >
> > The current problem is that I don't know where the bottleneck is, block
> > I/O layer, SCSI layer, device driver layer or hardware problem......
>
> AFAIK, anticipatory doesn't interact very well with queued devices. Can
> you try with deadline?
>
By using deadline, we observed the performance gain by NCQ. To avoid
jitter, I record 6 "average throughput per process" results for NCQ and
non-NCQ:
NCQ:
write :192 204 193 190 187 197
re-write :64 64 51 61 55 72
non-NCQ:
write :192 188 206 201 189 200
re-write :36 37 40 39 37 41
Here we observed that NCQ has a better re-write performance than non-
NCQ.
But when using anticipatory, the test result is:
NCQ:
write: 233
re-write: 197
non-NCQ:
write: 283
re-write: 332
Here we observed that anticipatory has a better performance than
deadline. Especially re-write under anticipatory has much better
performance than the one under deadline. So why users use deadline
instead of anticipatory?
Thanks,
Forrest
next prev parent reply other threads:[~2006-05-17 3:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-16 10:01 A question about NCQ zhao, forrest
2006-05-16 10:49 ` Tejun Heo
2006-05-17 2:21 ` zhao, forrest
2006-05-17 2:37 ` Tejun Heo
2006-05-17 3:24 ` zhao, forrest [this message]
2006-05-17 3:54 ` Tejun Heo
2006-05-17 4:04 ` Nick Piggin
2006-05-17 3:19 ` Jeff Garzik
2006-05-17 3:50 ` zhao, forrest
2006-05-17 14:31 ` Mark Lord
2006-05-18 1:56 ` Tejun Heo
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=1147836269.7273.127.camel@forrest26.sh.intel.com \
--to=forrest.zhao@intel.com \
--cc=htejun@gmail.com \
--cc=linux-ide@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).