On Wed, 2003-06-11 at 23:20, Nick Piggin wrote:

> 
> I think the cpu utilization gain of waking a number of tasks
> at once would be outweighed by advantage of waking 1 task
> and not putting it to sleep again for a number of requests.
> You obviously are not claiming concurrency improvements, as
> your method would also increase contention on the io lock
> (or the queue lock in 2.5).

I've been trying variations on this for a few days, none have been
thrilling but the end result is better dbench and iozone throughput
overall.  For the 20 writer iozone test, rc7 got an average throughput
of 3MB/s, and yesterdays latency patch got 500k/s or so.  Ouch.

This gets us up to 1.2MB/s.  I'm keeping yesterday's
get_request_wait_wake, which wakes up a waiter instead of unplugging.

The basic idea here is that after a process is woken up and grabs a
request, he becomes the batch owner.  Batch owners get to ignore the
q->full flag for either 1/5 second or 32 requests, whichever comes
first.  The timer part is an attempt at preventing memory pressure
writers (who go 1 req at a time) from holding onto batch ownership for
too long.  Latency stats after dbench 50:

device 08:01: num_req 120077, total jiffies waited 663231
        65538 forced to wait
        1 min wait, 175 max wait
        10 average wait
        65296 < 100, 242 < 200, 0 < 300, 0 < 400, 0 < 500
        0 waits longer than 500 jiffies

Good latency system wide comes from fair waiting, but it also comes from
how fast we can run write_some_buffers(), since that is the unit of
throttling.  Hopefully this patch decreases the time it takes for
write_some_buffers over the past latency patches, or gives someone else
a better idea ;-)

Attached is an incremental over yesterday's io-stalls-5.diff.

-chris