Messages in this thread | | | Date | Thu, 26 Jun 2003 23:18:08 +1000 | From | Nick Piggin <> | Subject | Re: [PATCH] io stalls |
| |
Nick Piggin wrote:
snip
> > Yeah, something like that. I think that in a queue full situation, > the processes are wanting to submit more than 1 request though. So > the better thoughput you can achieve by batching translates to > better effective throughput. Read my recent debate with Andrea
^^^^^^^^^^ Err, latency
snip
> > No, the numbers (batch # requests, batch time) are not highly scientific. > Simply when a process wakes up, we'll let them submit a small burst of > requests before they go back to sleep.
by this, I mean that its not a big problem that we don't know how many requests a process wants to submit.
snip
> > The changes do seem to be a critical fix due to the starvation issue, > but I'm worried that they take a big step back in performance under > high disk load. I found my FIFO mechanism to be unacceptably slow for > 2.5.
BTW. sorry for the lack of better benchmark numbers. I couldn't find good ones lying around. I found uniprocessor tiobench to be quite helpful at queue_nr_requests * 0.5, 2 threads to measure different types of overloadedness.
Also, I didn't see much gain in read performance in my testing - probably due to AS. I expect 2.4 and 2.5 non AS read performance to show bigger improvements from batching (ie. regressions).
- 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/
| |