Re: [PATCH] speed up SATA

[Jens Axboe <axboe@suse.de>]

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