Messages in this thread | | | Date | Thu, 12 Jun 2003 12:51:30 +1000 | From | Nick Piggin <> | Subject | Re: [PATCH] io stalls |
| |
Nick Piggin wrote:
> > > Andrea Arcangeli wrote: > >> 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. >> >> > That is pretty pointless as well. You might as well just start > waking up at the queue full limit, and wake one at a time. > > The purpose for batch_requests was I think for devices with a > very small request size, to reduce context switches.
I guess you could fix this by having a "last woken" flag, and allow that process to allocate requests without blocking from the batch limit until the queue full limit. That is how batch_requests is supposed to work.
- 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/
| |