linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Helge Hafting <helgehaf@aitel.hist.no>
To: Margit Schubert-While <margitsw@t-online.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Optimal SCSI Commands per device (TCQ) ?
Date: Wed, 13 Nov 2002 15:36:50 +0100	[thread overview]
Message-ID: <3DD26382.692BD476@aitel.hist.no> (raw)
In-Reply-To: 4.3.2.7.2.20021113133414.00b53b00@mail.dns-host.com

Margit Schubert-While wrote:
> 
> What is the optimal TCQ for eg. AIC7xxxx on Adaptec 39160
> with 2 x U160 disks on each channel ? (MAN3184MP and
> DDYS-T18350N)
> What does it depend on ?

The optimal depends on what you do, so the best
way to get a good answer is to try several
settings and see what works best.

Generally, a deeper tagged queue gives
better throughput.  The difference
is biggest when going from 0 to 1.
Making the queues progressively deeper
gives even more throughput, but the 
improvement diminishes quickly.

You have to look up how deep queues your disks
support, because this is variable among 
different models.  Some might max out at 8,
others can handle 256. There seems to be little
benefit at all beyond 32.

There is currently a downside to deep queues.
Linux v. 2.5 has a fair io scheduler that ensures
that no process waits "too long" for its
disk accesses.  This is particularly
important for reads.  A deep tagged
queue may improve total throughput, but
this may defeat the io scheduler so
processes doing random reads get starved
waiting for processes doing large linear
reads or writes.  

If this don't bother you, go for a deep
queue like 32 perhaps. If you want fairness
(users wait for response, i.e. desktop
machine or file/web server for multiple
people) go for something more shallow.

I have seen recommendations as low as 2-4 tags
to let the io scheduler enforce fairness.
2-4 tags is a lot better than none, going
from 4 to 32 probably makes less difference
than from 0 to 4. 

For an example of what a fair scheduler does,
look at previously posted benchmarks with
kernel compiles during a dbench run on the same disk.
Without fairness the compile takes many times longer.
with fairness the compile time is almost the same
as when compiling without the additional burden of a dbench.

Helge Hafting

  reply	other threads:[~2002-11-13 14:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-13 12:41 Optimal SCSI Commands per device (TCQ) ? Margit Schubert-While
2002-11-13 14:36 ` Helge Hafting [this message]
2002-11-13 16:50   ` cardbus card behind a pci to pci bridge Harald Jung
2002-11-13 15:33     ` Russell King

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=3DD26382.692BD476@aitel.hist.no \
    --to=helgehaf@aitel.hist.no \
    --cc=linux-kernel@vger.kernel.org \
    --cc=margitsw@t-online.de \
    /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).