From: Mark Rustad <mrustad@gmail.com>
To: Jeff Garzik <jeff@garzik.org>
Cc: Justin Piszcz <jpiszcz@lucidpixels.com>,
linux-kernel@vger.kernel.org,
IDE/ATA development list <linux-ide@vger.kernel.org>
Subject: Re: Why is NCQ enabled by default by libata? (2.6.20)
Date: Tue, 27 Mar 2007 13:18:05 -0500 [thread overview]
Message-ID: <ACBD2F44-03C7-49BE-9A2F-ABF7078BCC5E@gmail.com> (raw)
In-Reply-To: <4608B2B9.7090503@garzik.org>
On Mar 27, 2007, at 12:59 AM, Jeff Garzik wrote:
> Justin Piszcz wrote:
>> Without NCQ, performance is MUCH better on almost every operation,
>> with the exception of 2-3 items.
>
> Variables to take into account:
>
> * the drive (NCQ performance wildly varies)
> * the IO scheduler
> * the filesystem (if not measuring direct to blkdev)
> * application workload (or in your case, benchmark tool)
> * in particular, the threaded-ness of the apps
>
> For the overwhelming majority of combinations, NCQ should not /
> hurt/ performance.
>
> For the majority of combinations, NCQ helps (though it may not be
> often that you use more than 4-8 tags).
>
> In some cases, NCQ firmware may be broken. There is a Maxtor
> firmware id, and some Hitachi ids that people are leaning towards
> recommending be added to the libata 'horkage' list.
Some other variables that we have noticed: Some drive firmware goes
into "stupid" mode when write cache is turned off. Meaning that it
does not reorder any queued operations. Of course if you really care
about your data, you don't really want to turn write cache on.
Also the controller used can have unfortunate interactions. For
example the Adaptec SAS controller firmware will never issue more
than two queued commands to a SATA drive (even though the firmware
will happily accept more from the driver), so even if an attached
drive is capable of reordering queued commands, its performance is
seriously crippled by not getting more commands queued up. In
addition, some drive firmware seems to try to bunch up queued command
completions which interacts very badly with a controller that queues
up so few commands. In this case turning NCQ off performs better
because the drive knows it can't hold off completions to reduce
interrupt load on the host – a good idea gone totally wrong when used
with the Adaptec controller.
Today SATA NCQ seems to be an area where few combinations work well.
It seems so bad to me that a whitelist might be better than a
blacklist. That is probably overstating it, but NCQ performance is
certainly a big problem.
--
Mark Rustad, MRustad@gmail.com
next prev parent reply other threads:[~2007-03-27 18:18 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-24 16:38 Justin Piszcz
2007-03-24 18:43 ` Alan Cox
2007-03-27 9:55 ` Justin Piszcz
2007-03-27 10:10 ` Tejun Heo
2007-03-27 10:30 ` Justin Piszcz
2007-03-27 5:59 ` Jeff Garzik
2007-03-27 14:26 ` Mark Lord
2007-03-27 18:18 ` Mark Rustad [this message]
2007-03-27 18:38 ` Jeff Garzik
2007-03-27 22:12 ` Mark Rustad
2007-03-31 12:55 ` Ric Wheeler
[not found] <fa.MhN9pBMjZID4rnTNn+fU01uZiss@ifi.uio.no>
2007-03-24 22:11 ` Robert Hancock
2007-03-27 16:16 linux
2007-03-27 16:25 ` Justin Piszcz
2007-03-27 16:41 ` linux
2007-03-27 16:44 ` Justin Piszcz
2007-03-27 16:58 ` linux
2007-03-27 17:03 ` Justin Piszcz
2007-03-28 14:42 ` Phillip Susi
2007-03-28 14:48 ` Jeff Garzik
2007-03-29 17:28 ` Phillip Susi
2007-03-29 18:40 ` linux
2007-03-29 18:51 ` Jeff Garzik
2007-03-29 21:35 ` Alan Cox
2007-03-29 21:47 ` David Schwartz
2007-03-30 16:33 ` Lennart Sorensen
[not found] <fa.NmF2xJwO4BeVbJrFRkf7oV9EYmQ@ifi.uio.no>
[not found] ` <fa.39luedDWsoqip+QMNtfAv8jvyNg@ifi.uio.no>
[not found] ` <fa.b1cZfpMNhZ0teK/UauKLDWw60Jc@ifi.uio.no>
[not found] ` <fa.xWaBy6HZTRTgI+PxinV8ajuOlJI@ifi.uio.no>
[not found] ` <fa.BiSx71HKysC9QIpS8DLip5BmfxI@ifi.uio.no>
2007-04-01 17:28 ` Robert Hancock
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=ACBD2F44-03C7-49BE-9A2F-ABF7078BCC5E@gmail.com \
--to=mrustad@gmail.com \
--cc=jeff@garzik.org \
--cc=jpiszcz@lucidpixels.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@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
all inboxes | Powered by JetHome®