Messages in this thread |  | | | Date | Thu, 3 Sep 2009 15:07:31 +0200 | | From | Jens Axboe <> | | Subject | Re: [RFC] cfq: adapt slice to number of processes doing I/O |
| |
On Thu, Sep 03 2009, Jeff Moyer wrote: > Corrado Zoccolo <czoccolo@gmail.com> writes: > > > When the number of processes performing I/O concurrently increases, a > > fixed time slice per process will cause large latencies. > > In the patch, if there are more than 3 processes performing concurrent > > I/O, we scale the time slice down proportionally. > > To safeguard sequential bandwidth, we impose a minimum time slice, > > computed from cfq_slice_idle (the idea is that cfq_slice_idle > > approximates the cost for a seek). > > > > I performed two tests, on a rotational disk: > > * 32 concurrent processes performing random reads > > ** the bandwidth is improved from 466KB/s to 477KB/s > > ** the maximum latency is reduced from 7.667s to 1.728 > > * 32 concurrent processes performing sequential reads > > ** the bandwidth is reduced from 28093KB/s to 24393KB/s > > ** the maximum latency is reduced from 3.781s to 1.115s > > > > I expect numbers to be even better on SSDs, where the penalty to > > disrupt sequential read is much less. > > Interesting approach. I'm not sure what the benefits will be on SSDs, > as the idling logic is disabled for them (when nonrot is set and they > support ncq). See cfq_arm_slice_timer.
Also, the problem with scaling the slice a lot is that throughput has a tendency to fall off a cliff at some point. Have you tried benchmarking buffered writes with reads?
-- Jens Axboe
|  |