Messages in this thread | | | Subject | Re: [PATCH] io stalls | From | Chris Mason <> | Date | 12 Jun 2003 07:57:56 -0400 |
| |
On Wed, 2003-06-11 at 22:41, Nick Piggin wrote:
> >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. >
We've got many flavors of the patch discussed in this thread, so this needs a little qualification. When get_request_wait_wakeup wakes one of the waiters (as in the patch I sent yesterday), you want to make sure that after you wake the first waiter there is a request available for the proccess he is going to wake up, and so on for each other waiter.
I did a quick test of this yesterday, and under the 20 proc iozone test, turning off batch_requests more than doubled the number of context switches hit during the run, I'm assuming this was from wakeups that failed to find requests.
I'm doing a few tests with Andrea's new get_request_wait_wakeup ideas and wake_up_nr.
-chris
- 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/
| |