lkml.org 
[lkml]   [2009]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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



    \
     
     \ /
      Last update: 2009-09-03 15:09    [W:0.021 / U:89.596 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site