1 files changed, 53 insertions, 0 deletions
diff --git a/results/classifier/118/performance/1126369 b/results/classifier/118/performance/1126369
new file mode 100644
index 000000000..dfeba58ab
--- /dev/null
+++ b/results/classifier/118/performance/1126369
@@ -0,0 +1,53 @@
+performance: 0.850
+graphic: 0.658
+device: 0.643
+semantic: 0.573
+architecture: 0.452
+kernel: 0.440
+boot: 0.419
+hypervisor: 0.413
+network: 0.411
+ppc: 0.394
+mistranslation: 0.392
+socket: 0.384
+vnc: 0.358
+risc-v: 0.355
+PID: 0.332
+files: 0.326
+permissions: 0.325
+x86: 0.325
+register: 0.315
+debug: 0.309
+arm: 0.302
+virtual: 0.297
+i386: 0.285
+VMM: 0.274
+peripherals: 0.258
+KVM: 0.258
+user-level: 0.257
+TCG: 0.238
+assembly: 0.198
+
+qemu-img snapshot -c is unreasonably slow
+
+Something fishy is going on with qcow2 internal snapshot creation times.  I don't know if this is a regression because I haven't used internal snapshots in the past.
+
+QEMU 1.4-rc2:
+$ qemu-img create -f qcow2 test.qcow2 -o size=50G,preallocation=metadata
+$ time qemu-img snapshot -c new test.qcow2
+real	3m39.147s
+user	0m10.748s
+sys	0m26.165s
+
+(This is on an SSD)
+
+I expect snapshot creation to take under 1 second.
+
+Skipping the bdrv_flush() in update_cluster_refcount() gives a huge speed-up from over 3 minutes down to <1 second.  I think Kevin already discovered this in the past.
+
+Now we need to figure out how to safely perform the updates without flushing after each L2 table refcount increment.
+
+Looking through old bug tickets... have this issue been fixed, i.e. could we close this ticket nowadays? Or is there still something left to do?
+
+Code inspection shows that qcow2_update_cluster_refcount() no longer calls bdrv_flush().  This issue has been fixed.
+