On Tue, Aug 3, 2010 at 5:14 PM, Avi Kivity <avi@xxxxxxxxxx> wrote: > On 08/03/2010 05:57 PM, John Leach wrote: >> >> On Tue, 2010-08-03 at 17:44 +0300, Avi Kivity wrote: >>> >>> On 08/03/2010 05:40 PM, John Leach wrote: >>>> >>>> dd if=/dev/mapper/zero of=/dev/null bs=8k count=1000000 iflag=direct >>>> 8192000000 bytes (8.2 GB) copied, 3.46529 s, 2.4 GB/s >>>> >>>> dd if=/dev/mapper/zero of=/dev/null bs=8k count=1000000 >>>> 8192000000 bytes (8.2 GB) copied, 5.5741 s, 1.5 GB/s >>>> >>>> dd is just using read. >>>> >>> What's /dev/mapper/zero? A real volume or a zero target? >>> >> zero target: >> >> echo "0 21474836480 zero" | dmsetup create zero >> >> The same performance penalty occurs when using real disks though, I just >> moved to a zero target to rule out the variables of spinning metal and >> raid controller caches. > > Don't, it's confusing things. I'd expect dd to be slower with iflag=direct > since the kernel can't do readahead an instead must roundtrip to the > controller. With a zero target it's faster since it doesn't have to > roundtrip and instead avoids a copy. I agree that the devicemapper zero target acts differently from a physical disk and you may wish to drop it in favor of realistic disk characteristics. Here is the virtio-ioeventfd patch which improves performance especially for multi-threaded workloads: http://repo.or.cz/w/qemu/stefanha.git/commitdiff/889460ccc86a0121df9c77a698f50bf007005b7f (The patch is against qemu.git not qemu-kvm.git.) A single-threaded dd will not benefit; it may see a small degradation due to additional latency. But I want to share this patch with you while I'm still testing and preparing it for upstream so you can take it on board for any benchmarking. Stefan -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
