Re: [PATCH] speed up SATA

[Jeff Garzik]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/