Messages in this thread | ![/](/images/icornerl.gif) | | Date | Fri, 21 Feb 2003 21:55:00 +1100 | From | Nick Piggin <> | Subject | Re: 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 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/
| ![\](/images/icornerr.gif) |