> >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/