Re: [PATCH] speed up SATA

Jens Axboe
2004-03-29T08:11:08Z

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