Messages in this thread | | | Date | Thu, 12 Jun 2003 04:46:08 +0200 | From | Andrea Arcangeli <> | Subject | Re: [PATCH] io stalls |
| |
On Thu, Jun 12, 2003 at 12:41:58PM +1000, Nick Piggin wrote: > > > 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.
it does nothing w/ _exclusive and w/o the wake_up_nr, that's why I added the wake_up_nr.
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/
| |