RE: 2.5.69, IDE TCQ can't be enabled

Mudama, Eric (eric_mudama@maxtor.com)
Tue, 13 May 2003 14:43:50 -0600


-----Original Message-----
>From: Andre Hedrick [mailto:andre@linux-ide.org]
>Sent: Tuesday, May 13, 2003 2:29 PM
>To: Jeff Garzik
>Cc: Jens Axboe; Dave Jones; Mudama, Eric; Oleg Drokin; Bartlomiej
>Zolnierkiewicz; Alan Cox; Oliver Neukum; lkhelp@rekl.yi.org;
>linux-kernel@vger.kernel.org
>Subject: Re: 2.5.69, IDE TCQ can't be enabled
>
>This is the last time I got TAG running clean!
>Proof you have zero gain on writes and huge gains on reads.

Of course there's no gain on writes with write cache enabled, that is
obvious:

It is nearly impossible for a drive to cache random reads, therefore they
have the greatest performance penalty due to seeks and rotational latency.
That is why queueing improves random reads so much.

Repetitive and Sequential reads should see no benefit at all from queueing,
since the virtually-zero-size drive cache actually hits its locality
(spatial or temporal) cases for these commands.

Similarly, any write with the drive's write cache enabled will see zero or
near-zero benefit from queueing writes. The only reason to use queued
writes is so you can intermingle them with queued reads without flushing
your tags.

If you disable write cache on the drive (Journalling/RAID environments) then
you'll see performance nearly identical to reads, which then can benefit by
queueing to the same degree.

>Still it is a lame protocol.

I don't necessarilly disagree, however I'm not on T13 and didn't have any
input.

--eric
-
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/