Messages in this thread | | | Date | Mon, 29 Mar 2004 10:09:45 +0200 | From | Jens Axboe <> | Subject | Re: [PATCH] speed up SATA |
| |
On Sun, Mar 28 2004, Jeff Garzik wrote: > >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); > ...
Oh god no, I was afraid you'd come up with something like this :-). I'm quite sure this will lead to an unmaintainable mess, as more and various different classes are introduced. Don't try to model something that you really cannot model.
> 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>.
Lets leave it like it is, and try and tweak latencies dynamically. Could be used to limit tcq depth, not just request sizes solving two problems at once. I already have a tiny bit of keeping this accounting to do proper unplugs (right now it just looks at missing requests from the pool, doesn't work on tcq).
-- Jens Axboe
- 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/
| |