On Tue, Sep 13, 2011 at 10:25 AM, Zhi Yong Wu <zwu.ker...@gmail.com> wrote: > On Tue, Sep 13, 2011 at 3:14 PM, Stefan Hajnoczi > <stefa...@linux.vnet.ibm.com> wrote: >> On Tue, Sep 13, 2011 at 10:52:44AM +0800, Zhi Yong Wu wrote: >>> This is real log when fio issued with bs=128K and bps=1000000(block >>> I/O throttling): >> >> I would use 1024 * 1024 instead of 1000000 as the throughput limit. >> 10^5 is not a multiple of 512 bytes and is not a nice value in KB/s >> (976.5625). > OK. next time, i will adopt this. >> >>> >>> 8,2 0 1 0.000000000 24332 A WS 79958528 + 256 <- >>> (253,2) 71830016 >> >> 256 blocks = 256 * 512 bytes = 128 KB per request. We know the maximum >> request size from Linux is 128 KB so this makes sense. >> >>> Throughput (R/W): 0KiB/s / 482KiB/s >> >> What throughput do you get without I/O throttling? Either I/O >> throttling is limiting too aggressively here or the physical disk is the >> bottleneck (I double that since the write throughput value is very low). >> We need to compare against the throughput when throttling is not >> enabled. > Without block I/O throttling. [...] > test: (g=0): rw=write, bs=128K-128K/128K-128K, ioengine=libaio, iodepth=1 > Starting 1 process > Jobs: 1 (f=1): [W] [100.0% done] [0K/13M /s] [0/103 iops] [eta 00m:00s] > test: (groupid=0, jobs=1): err= 0: pid=2734 > write: io=51,200KB, bw=12,933KB/s, iops=101, runt= 3959msec
This shows that the physical disk is capable of far exceeding 1 MB/s when I/O is not limited. So the earlier result where the guest only gets 482 KiB/s under 1000000 bps limit shows that I/O limits are being too aggressive. For some reason the algorithm is causing the guest to get lower throughput than expected. It would be interesting to try with bps=$((10 * 1024 * 1024)). I wonder if the algorithm has a constant overhead of a couple hundred KB/s or if it changes with the much larger bps value. Stefan
