Messages in this thread | | | Date | Sun, 28 Mar 2004 20:31:40 -0800 | From | William Lee Irwin III <> | Subject | Re: [PATCH] speed up SATA |
| |
On Mon, Mar 29, 2004 at 02:55:02AM +0200, Andrea Arcangeli wrote: > The point is that if you run read contigously from disk with a 1M or 32M > request size, the wall time speed difference will be maybe 0.01% or so. > Running 100 irqs per second or 3 irq per second doesn't make any > measurable difference. Same goes for keeping the I/O pipeline full, 1M > is more than enough to go at the speed of the storage with minimal cpu > overhead. we waste 900 irqs per second just in the timer irq and > another 900 irqs per second per-cpu in the per-cpu local interrupts in > smp. > In 2.4 reaching 512k DMA units that helped a lot, but going past 512k > didn't help in my measurements. 1M maybe these days is needed (as Jens > suggested) but >1M still sounds overkill and I completely agree with > Jens about that.
Maybe we should try this the other way around. Assume those who want larger request sizes are rational (unlikely as that may be) for the sake of argument; what could they possibly be after? I'm thinking that once we know what they're really after we might be able to satisfy the needs some other way that makes more sense for the general case.
I have a wild guess it may reduce interrupt load and/or overhead of request submission to the HBA by the factor of the request size increase as the number of spindles (and of course the RAM with which to do buffering) grows without bound, but otherwise no real notion of why on earth anyone could want it. Maybe we should find out who (if anyone) claims they really want the unreasonably large requests first so they can be asked directly.
-- wli - 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/
| |