diff options
Diffstat (limited to 'results/classifier/zero-shot/108/other/1126369')
| -rw-r--r-- | results/classifier/zero-shot/108/other/1126369 | 38 |
1 files changed, 38 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/other/1126369 b/results/classifier/zero-shot/108/other/1126369 new file mode 100644 index 000000000..10ab5001a --- /dev/null +++ b/results/classifier/zero-shot/108/other/1126369 @@ -0,0 +1,38 @@ +performance: 0.850 +graphic: 0.658 +device: 0.643 +semantic: 0.573 +boot: 0.419 +network: 0.411 +other: 0.396 +socket: 0.384 +vnc: 0.358 +PID: 0.332 +files: 0.326 +permissions: 0.325 +debug: 0.309 +KVM: 0.258 + +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. + |