[lkml]   [2003]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: iosched: impact of streaming read on read-many-files
    Andrea Arcangeli wrote:

    >On Thu, Feb 20, 2003 at 09:27:58PM -0800, Andrew Morton wrote:
    >>Here we look at what affect a large streaming read has upon an operation
    >>which reads many small files from the same disk.
    >>A single streaming read was set up with:
    >> while true
    >> do
    >> cat 512M-file > /dev/null
    >> done
    >>and we measure how long it takes to read all the files from a 2.4.19 kernel
    >>tree off the same disk with
    >> time (find kernel-tree -type f | xargs cat > /dev/null)
    >>2.4.21-pre4: 31 minutes 30 seconds
    >>2.5.61+hacks: 3 minutes 39 seconds
    >>2.5.61+CFQ: 5 minutes 7 seconds (*)
    >>2.5.61+AS: 17 seconds
    >>* CFQ performed very strangely here. Tremendous amount of seeking and a
    >strangely? this is the *feature*. Benchmarking CFQ in function of real
    >time is pointless, apparently you don't understand the whole point about
    >CFQ and you keep benchmarking like if CFQ was designed for a database
    >workload. the only thing you care if you run CFQ is the worst case
    >latency of read, never the throughput, 128k/sec is more than enough as
    >far as you never wait 2 seconds before you can get the next 128k.
    >take tiobench with 1 single thread in read mode and keep it running in
    >background and collect the worst case latency, only *then* you will have
    >a chance to see a benefit. CFQ is all but a generic purpose elevator.
    >You must never use CFQ if your object is throughput and you benchmark
    >the global workload and not the worst case latency of every single read
    >or write-sync syscall.
    >CFQ is made for multimedia desktop usage only, you want to be sure
    >mplayer or xmms will never skip frames, not for parallel cp reading
    >floods of data at max speed like a database with zillon of threads. For
    >multimedia not to skip frames 1M/sec is more than enough bandwidth,
    >doesn't matter if the huge database in background runs much slower as
    >far as you never skip a frame.
    >If you don't mind to skip frames you shouldn't use CFQ and everything
    >will run faster, period.
    There is actually a point when you have a number of other IO streams
    going on where your decreased throughput means *maximum* latency goes
    up because robin doesn't go round fast enough. I guess desktop loads
    won't often have a lot of different IO streams.

    The anticipatory scheduler isn't so strict about fairness, however it
    will make as good an attempt as CFQ at keeping maximum read latency
    below read_expire (actually read_expire*2 in the current implementation).

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:33    [W:0.029 / U:30.360 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site