Re: [PATCH] speed up SATA

From: Jeff Garzik
Date: Sun Mar 28 2004 - 13:58:21 EST

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

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


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at