Re: [PATCH] speed up SATA

Jeff Garzik
2004-03-28T18:56:21Z

Jens Axboe wrote:
> On Sun, Mar 28 2004, Jamie Lokier wrote:
>
>>Jens Axboe wrote:
>>
>>>Sorry, but I cannot disagree more. You think an artificial limit at
>>>the block layer is better than one imposed at the driver end, which
>>>actually has a lot more of an understanding of what hardware it is
>>>driving? This makes zero sense to me. Take floppy.c for instance, I
>>>really don't want 1MB requests there, since that would take a minute
>>>to complete. And I might not want 1MB requests on my Super-ZXY
>>>storage, because that beast completes io easily at an iorate of
>>>200MB/sec.
>>
>>The driver doesn't know how fast the drive is either.
>>
>>Without timing the drive, interface, and for different request sizes,
>>neither the block layer _nor_ the driver know a suitable size.

Nod, this is pretty much my objection to hardcoding an artificial limit
in the driver...

> The driver may not know exactly, but it does know a ball park figure.
> You know if you are driving floppy (sucky transfer and latency), hard
> drive, cdrom (decent transfer, sucky seeks), etc.

Agreed. Really we have two types of information:
* the device's hard limit
* the default limit that should be applied to that class of devices

I would much rather do something like

blk_queue_set_class(q, CLASS_DISK)

and have that default per-class policy

switch (class) {
case CLASS_DISK:
q->max_sectors = min(q->max_sectors, CLASS_DISK_MAX_SECTORS);
...

than hardcode the limit in the driver. That's easy and quick. That's a
minimal solution that gives me what I want -- don't hardcode generic
limits in the driver -- while IMO giving you what you want, a sane limit
in an easy way.

Right now we are hardcoding the same per-class limits into each floppy
driver, each disk driver, etc. At the very least devices that act the
same way should all be using the same tunable, whether it's a
compile-time tunable (CLASS_xxx_MAX_SECTORS) or a runtime tunable.

Long term, the IO scheduler and the VM should really be figuring out the
best request size, from zero to <hardware limit>.

Jeff