Re: [PATCH] speed up SATA

[Jeff Garzik <jgarzik@pobox.com>]

Jens Axboe wrote:
> On Sun, Mar 28 2004, Jeff Garzik wrote:
> 
>>Jens Axboe wrote:
>>
>>>On Sat, Mar 27 2004, Jeff Garzik wrote:
>>>
>>>
>>>>I also wouldn't want to lock out any users who wanted to use SATA at 
>>>>full speed ;-)
>>>
>>>
>>>And full speed requires 32MB requests?
>>
>>
>>Full speed is the SATA driver supporting the hardware maximum.  The 
> 
> 
> Come on Jeff, don't be such a slave to the hardware specifications. Just
> because it's possible to send down 32MB requests doesn't necessarily
> mean it's a super thing to do, nor that it automagically makes 'things
> go faster'. The claim is that back-to-back 1MB requests are every bit as
> fast as a 32MB request (especially if you have a small queue depth, in
> that case there truly should be zero benefit to doing the bigger ones).
> The cut-off point is likely even lower than 1MB, I'm just using that
> figure as a value that is 'pretty big' yet doesn't incur too large
> latencies just because of its size.


For me this is a policy issue.

I agree that huge requst hurt latency.  I just disagree that the 
_driver_ should artificially lower its maximums to fit a guess about 
what the best request size should be.

If there needs to be an overall limit on per-size size, do it at the 
block layer.  It's not scalable to hardcode that limit into every 
driver.  That's not the driver's job.  The driver just exports the 
hardware limits, nothing more.

A limit is fine.  I support that.  An artificial limit in the driver is not.

	Jeff