lkml.org 
[lkml]   [2004]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.102 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site