Re: [PATCH] io stalls

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

Chris Mason wrote:

>On Wed, 2003-06-11 at 21:29, Andrea Arcangeli wrote:
>
>
>>this will avoid get_request_wait_wakeup to mess the wakeup, so we can
>>wakep_nr(rq.count) safely.
>>
>>then there's the last issue raised by Chris, that is if we get request
>>released faster than the tasks can run, still we can generate a not
>>perfect fairness. My solution to that is to change wake_up to have a
>>nr_exclusive not obeying to the try_to_wakeup retval. that should
>>guarantee exact FIFO then, but it's a minor issue because the requests
>>shouldn't be released systematically in a flood. So I'm leaving it
>>opened for now, the others already addressed should be the major ones.
>>
>
>I think the only time we really need to wakeup more than one waiter is
>when we hit the q->batch_request mark.  After that, each new request
>that is freed can be matched with a single waiter, and we know that any
>previously finished requests have probably already been matched to their
>own waiter.
>
>
Nope. Not even then. Each retiring request should submit
a wake up, and the process will submit another request.
So the number of requests will be held at the batch_request
mark until no more waiters.

Now that begs the question, why have batch_requests anymore?
It no longer does anything.