Re: [PATCH] speed up SATA

[Jeff Garzik]

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

I would rather have a sane block layer default, that works without my 
intervention :)

Ditto the max_sectors issue, the driver for the hardware w/ a 256-depth 
queue should attempt to queue up to the hardware maximum.  The block 
layer can be smart and limit things further from there...

IIRC the AIC7xxx driver sets the queue depth to 200+ on one of my 
drives.  That may be 2.4, though...


> 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.)

Most ATA drives have their own internal disk schedulers, and all of the 
major vendors seem to have done something useful with TCQ.  Newer drives 
definitely take advantage of the additional knowledge gained via 
knowledge of the entire queue rather than just a single request.

The parallel-reads case you mention is definitely a winner with TCQ, but 
writes are also, for ATA-specific reasons (among others):  since ATA has 
been one-command-at-a-time for so long, write caching became necessary 
for decent performance.  So ATA disks needed a decent internal IO 
scheduler, just maintain a decent level of performance.

TCQ-on-write for ATA disks is yummy because you don't really know what 
the heck the ATA disk is writing at the present time.  By the time the 
Linux disk scheduler gets around to deciding it has a nicely merged and 
scheduled set of requests, it may be totally wrong for the disk's IO 
scheduler.  TCQ gives the disk a lot more power when the disk integrates 
writes into its internal IO scheduling.

	Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/