Re: [PATCH] speed up SATA

[Jamie Lokier]

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.

> I absolutely refuse to put a global block layer 'optimal io
> size' restriction in, since that is the ugliest of policies and
> without having _any_ knowledge of what the hardware can do.

But the driver doesn't have _any_ knowledge of what the I/O scheduler
wants.  1MB requests may be a cut-off above which there is negligable
throughput gain for SATA, but those requests may be _far_ too large
for a low-latency I/O scheduling requirement.

If we have a high-level latency scheduling constraint that userspace
should be able to issue a read and get the result within 50ms, or that
the average latency for reads should be <500ms, how does the SATA
driver limiting requests to 1MB help?  It depends on the attached drive.

The fundamental problem here is that neither the driver nor the block
layer have all the information needed to select optimal or maximum
request sizes.  That can only be found by timing the device, perhaps
every time a request is made, and adjusting the I/O scheduling and
request splitting parameters according to that timing and high-level
latency requirements.

>From that point of view, the generic block layer is exactly the right
place to determine those parameters, because the calculation is not
device-specific.

-- Jamie
-
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/