lkml.org 
[lkml]   [2004]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] speed up SATA
Jeff Garzik wrote:
> Jeff Garzik wrote:
>
>> It's up to the sysadmin to choose a disk scheduling policy they like,
>> which implies that a _scheduler_, not each individual driver, should
>> place policy limitations on max_sectors.
>
>
>
> <tangent>
>
> The block layer / scheduler guys should also think about a general (not
> SCSI specific) way to tune TCQ tag depth. That's IMO another policy
> decision.
>
> I'm about to add a raft of SATA-2 hardware, all of which are queued. The
> standard depth is 32, but one board supports a whopping depth of 256.
>
> Given past discussion on the topic, you probably don't want to queue 256
> requests at a time to hardware :) But the sysadmin should be allowed
> to, if they wish...

I think you could limit the number of in-flight requests quite
easily, even for drivers that do not use the block layer's
queueing functions.

Aside, you should make 2 or 4 tags the default though: that
still gives you the pipelining without sacrificing latency
and usibility.

The only area (I think) where large queues outperform the IO
scheduler are lots of parallel, scattered reads. I think this
is because the drive can immediately return cached data even
though it looks like a large seek to the IO scheduler.
(This is from testing on my single, old SCSI disk though.)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.174 / U:0.316 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site