1 files changed, 69 insertions, 0 deletions
diff --git a/results/classifier/111/performance/498417 b/results/classifier/111/performance/498417
new file mode 100644
index 000000000..f69096f91
--- /dev/null
+++ b/results/classifier/111/performance/498417
@@ -0,0 +1,69 @@
+performance: 0.149
+other: 0.115
+semantic: 0.082
+permissions: 0.075
+device: 0.072
+vnc: 0.069
+graphic: 0.063
+socket: 0.059
+PID: 0.059
+network: 0.058
+files: 0.055
+KVM: 0.051
+debug: 0.048
+boot: 0.043
+performance: 0.896
+KVM: 0.034
+vnc: 0.015
+debug: 0.009
+PID: 0.006
+device: 0.006
+socket: 0.006
+other: 0.006
+files: 0.006
+semantic: 0.004
+graphic: 0.004
+boot: 0.003
+network: 0.002
+permissions: 0.002
+
+cache=writeback on disk image doesn't do write-back
+
+I noticed that qemu seems to have poor disk performance.  Here's a test that has miserable performance but which should be really fast:
+
+- Configure qemu to use the disk image with cache=writeback
+- Configure a 2GiB Linux VM on an 8GiB Linux host
+- In the VM, write a 4GiB file (dd if=/dev/zero of=/tmp/x bs=4K count=1M)
+- In the VM, read it back (dd if=/tmp/x of=/dev/null bs=4K count=1M)
+
+With writeback, the whole file should end up in the host pagecache.  So when I read it back, there should be no I/O to the real disk, and it should be really fast.  Instead, I see disk activity through the duration of the test, and the performance is roughly the native hard disk throughput (somewhat slower).
+
+I'm using version 0.11.1, and this is my command line:
+
+qemu-system-x86_64 -drive cache=writeback,index=0,media=disk,file=ubuntu.img -k en-us -m 2048 -smp 2 -vnc :3100 -usbdevice tablet -enable-kvm &
+
+Can you please try reproducing with 0.12.1?
+
+I'm using 0.12.1.2.  With this command line:
+
+qemu-system-x86_64 -drive cache=writeback,index=0,media=disk,file=ubuntu.img -k en-us -m 2048 -smp 2 -vnc :3102 -usbdevice tablet -enable-kvm &
+
+Here's what I'm seeing:
+
+With "dd if=/dev/zero of=./x bs=1024k count=1024", I get at best 29 MiB/sec.  
+
+This fits in the VM, so with "dd if=/dev/zero of=./x bs=1024k count=1024", which spills into the host, I get at best 25 MiB/sec.  (I am aware that with the expanding qcow2 disk image, there's also some overhead for allocating space during the write, so I run the same test multiple times and report the best result.)
+
+Since I'm using writeback, I would expect to see much faster write performance.  This is slower than the host's disk performance with fsync involved.  Is there an fsync going on here?  Is dd doing an fsync?  That should sync the VM's disk.  But then is there an ATA command to sync the drive that qemu interprets as a request to sync the disk image?  It would be "safe" to take this hint, but since I'm explicitly requesting writeback, I'm not expecting "safe".  I'm intentionally defeating "safe" for the sake of performance, with full knowledge of the risks.
+
+With "dd if=./x of=/dev/null bs=1024k count=1024", it varies a LOT, but I've gotten as much as 4.9GiB/sec and as little as 2.5GiB/sec.  This is WAY better than what I was getting with 0.11.1.
+
+With "dd if=./x of=/dev/null bs=1024k count=4096", the best I get is 460MiB/sec.  That's still very good.  Could be better, but the overhead of emulating SATA has got to be really high under any circumstances.
+
+Using a VM imposes a lot of overhead that makes the guest OS quite a bit slower than running it directly on the hardware.  I'm trying to make up for this by using the rest of my hosts RAM (more or less) as a huge disk cache.
+
+
+QEMU 0.11 / 0.12 is pretty much outdated nowadays ... can you still reproduce this issue with the latest version of QEMU?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+