|From:||Jens Axboe <axboe-AT-suse.de>|
|To:||Jeff Garzik <jgarzik-AT-pobox.com>|
|Subject:||Re: [PATCH] speed up SATA|
|Date:||Sun, 28 Mar 2004 19:54:36 +0200|
|Cc:||Nick Piggin <nickpiggin-AT-yahoo.com.au>, linux-ide-AT-vger.kernel.org, Linux Kernel <linux-kernel-AT-vger.kernel.org>, Andrew Morton <akpm-AT-osdl.org>|
On Sun, Mar 28 2004, Jeff Garzik wrote: > Jens Axboe wrote: > >On Sun, Mar 28 2004, Jeff Garzik wrote: > > > >>Jens Axboe wrote: > >> > >>>On Sat, Mar 27 2004, Jeff Garzik wrote: > >>> > >>> > >>>>I also wouldn't want to lock out any users who wanted to use SATA at > >>>>full speed ;-) > >>> > >>> > >>>And full speed requires 32MB requests? > >> > >> > >>Full speed is the SATA driver supporting the hardware maximum. The > > > > > >Come on Jeff, don't be such a slave to the hardware specifications. Just > >because it's possible to send down 32MB requests doesn't necessarily > >mean it's a super thing to do, nor that it automagically makes 'things > >go faster'. The claim is that back-to-back 1MB requests are every bit as > >fast as a 32MB request (especially if you have a small queue depth, in > >that case there truly should be zero benefit to doing the bigger ones). > >The cut-off point is likely even lower than 1MB, I'm just using that > >figure as a value that is 'pretty big' yet doesn't incur too large > >latencies just because of its size. > > > For me this is a policy issue. > > I agree that huge requst hurt latency. I just disagree that the > _driver_ should artificially lower its maximums to fit a guess about > what the best request size should be. > > If there needs to be an overall limit on per-size size, do it at the > block layer. It's not scalable to hardcode that limit into every > driver. That's not the driver's job. The driver just exports the > hardware limits, nothing more. > > A limit is fine. I support that. An artificial limit in the driver > is not. 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. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Copyright © 2004, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds