Re: [PATCH] speed up SATA

[Jens Axboe]

On Sun, Mar 28 2004, William Lee Irwin III wrote:
> On Sun, Mar 28, 2004 at 07:54:36PM +0200, 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.
> > So you want to put this _policy_ in the block layer, instead of in the
> > driver. That's an even worse decision if your reasoning is policy. The
> > only such limits I would want to put in, are those of the bio where
> > simply is best to keep that small and contained within a single page to
> > avoid higher order allocations to do io. Limits based on general sound
> > principles, not something that caters to some particular piece of
> > hardware. 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.
> 
> How about per-device policies and driver hints wrt. optimal io?

That would be fine, it's what I suggested in an earlier email. In the
future Jamie's suggestion is probably the one that makes the most sense
- just keep a per-driver limit setting which informs the block layer of
max sectors the hardware truly can do, and try and time request
execution if you care about latencies.

But lets not forget the original question, which is when and if 32MB
request make sense at all. Right now they probably don't.

-- 
Jens Axboe

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