mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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



  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®