Messages in this thread | | | Date | Fri, 21 Feb 2003 12:41:43 +0100 | From | Andrea Arcangeli <> | Subject | Re: IO scheduler benchmarking |
| |
On Fri, Feb 21, 2003 at 10:17:55PM +1100, Nick Piggin wrote: > Andrea Arcangeli wrote: > > >it's like a dma ring buffer size of a soundcard, if you want low latency > >it has to be small, it's as simple as that. It's a tradeoff between > > > Although the dma buffer is strictly FIFO, so the situation isn't > quite so simple for disk IO.
In genereal (w/o CFQ or the other side of it that is an extreme unfair starving elevator where you're stuck regardless the size of the queue) larger queue will mean higher latencies in presence of flood of async load like in a dma buffer. This is obvious for the elevator noop for example.
I'm speaking about a stable, non starving, fast, default elevator (something like in 2.4 mainline incidentally) and for that the similarity with dma buffer definitely applies, there will be a latency effect coming from the size of the queue (even ignoring the other issues that the load of locked buffers introduces).
The whole idea of CFQ is to make some workload work lowlatency indipendent on the size of the async queue. But still (even with CFQ) you have all the other problems about write throttling and worthless amount of locked ram and even wasted time on lots of full just ordered requests in the elevator (yeah I know you use elevator noop won't waste almost any time, but again this is not most people will use). I don't buy Andrew complaining about the write throttling when he still allows several dozen mbytes of ram in flight and invisible to the VM, I mean, before complaining about write throttling the excessive worthless amount of locked buffers must be fixed and so I did and it works very well from the feedback I had so far.
You can take 2.4.21pre4aa3 and benchmark it as you want if you think I'm totally wrong, the elevator-lowlatency should be trivial to apply and backout (benchmarking against pre4 would be unfair).
Andrea - 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/
| |