linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <htejun@gmail.com>
To: Mark Lord <liml@rtr.ca>
Cc: "zhao, forrest" <forrest.zhao@intel.com>, linux-ide@vger.kernel.org
Subject: Re: A question about NCQ
Date: Thu, 18 May 2006 10:56:50 +0900	[thread overview]
Message-ID: <446BD462.9030606@gmail.com> (raw)
In-Reply-To: <446B33D6.7040006@rtr.ca>

Mark Lord wrote:
> zhao, forrest wrote:
> ..
>> But initial test result of running iozone with O_DIRECT option turned on
>> didn't show the visible performance gain with NCQ. In certain cases, NCQ
>> even had a worse performance than without NCQ.
>>
>> So my question is in what usage case can we observe the performance gain
>> with NCQ?
> 
> That's something I've been wondering for a couple of years,
> ever since implementing full NCQ/TCQ Linux drivers for several devices
> (most notably the very fast qstor.c driver).
> 
> The observation with all of thses was that Linux already does a reasonably
> good enough job of scheduling I/O that tagged-queuing rarely seems to help,
> at least on any benchmark/test tools we've found to try (note that opposite
> results are obtained when using non-Linux kernels, eg. winxp).
> 
> With some drives, the use of tagged commands triggers different firmware
> algorithms, that adversely affect throughput in favour of better random
> seek capability -- but since the disk scheduling already minimizes the
> randomness of seeking (very few back-and-forth flurries), this combination
> often ends up slower than without NCQ (on Linux).

At this point, NCQ doesn't look that attractive as it shows _worse_ 
performance on many cases.  Maybe libata shouldn't enable it 
automatically for the time being but I think if drives handle NCQ 
reasonably well, there are things to be gained from NCQ by making IO 
schedulers more aware of queued devices.  Things that come to my mind are...

* Control the movement of head closely but send adjacent requests 
together to allow the drive optimize at smaller scale.

* Reduce plugging/wait latency.  As we can send more than one command at 
a time, we don't have to wait for adjacent requests which might arrive 
soon.  If it's once determined that the head can move to certain area, 
issue the command ASAP.  If adjacent requests arrive, we can merge them 
while the head is moving thus reducing latency.

-- 
tejun

      reply	other threads:[~2006-05-18  2:50 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
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 [this message]

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=446BD462.9030606@gmail.com \
    --to=htejun@gmail.com \
    --cc=forrest.zhao@intel.com \
    --cc=liml@rtr.ca \
    --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).