Re: [PATCH] io stalls

[Nick Piggin <piggin@cyberone.com.au>]

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).