Messages in this thread | | | Date | Sun, 28 Mar 2004 13:55:43 -0500 | From | Jeff Garzik <> | Subject | Re: [PATCH] speed up SATA |
| |
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
- 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/
| |