Messages in this thread | | | From | Bartlomiej Zolnierkiewicz <> | Subject | Re: [PATCH] speed up SATA | Date | Sun, 28 Mar 2004 20:45:07 +0200 |
| |
On Sunday 28 of March 2004 20:30, Jens Axboe wrote: > On Sun, Mar 28 2004, Bartlomiej Zolnierkiewicz wrote: > > On Sunday 28 of March 2004 20:12, 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? > > > > Yep, user-tunable per-device policies with sane driver defaults. > > BTW, these are trivial to expose through sysfs as their as inside the > queue already.
Yep, yep.
> Making something user tunable is usually not the best idea, if you can > deduct these things automagically instead. So whether this is the best > idea, depends on which way you want to go.
I think it's the best idea for now, long-term we are better with automagic.
Bartlomiej
- 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/
| |