1 files changed, 48 insertions, 0 deletions
diff --git a/results/classifier/118/none/1338957 b/results/classifier/118/none/1338957
new file mode 100644
index 000000000..158007a5f
--- /dev/null
+++ b/results/classifier/118/none/1338957
@@ -0,0 +1,48 @@
+performance: 0.761
+semantic: 0.689
+graphic: 0.680
+device: 0.640
+ppc: 0.590
+architecture: 0.539
+files: 0.520
+socket: 0.515
+network: 0.493
+mistranslation: 0.477
+vnc: 0.475
+peripherals: 0.463
+boot: 0.459
+register: 0.455
+risc-v: 0.451
+hypervisor: 0.438
+kernel: 0.419
+virtual: 0.418
+i386: 0.410
+VMM: 0.402
+PID: 0.333
+permissions: 0.305
+TCG: 0.298
+x86: 0.276
+KVM: 0.241
+debug: 0.240
+assembly: 0.231
+arm: 0.225
+user-level: 0.118
+
+RFE: add an event to report block devices watermark
+
+Add an event to report if a block device usage exceeds a threshold. The threshold should be configurable with a monitor command. The event should report the affected block device. Additional useful information could be the offset of the highest sector , like in the query-blockstats output.
+
+Rationale for the RFE
+Managing applications, like oVirt (http://www.ovirt.org), make extensive use of thin-provisioned disk images.
+In order to let the guest run flawlessly and be not unnecessarily paused, oVirt sets a watermark and automatically resized the image once the watermark is reached or exceeded.
+
+In order to detect the mark crossing, the managing application has no choice than aggressively polling the QEMU monitor
+using the query-blockstats command. This lead to unnecessary system load, and is made even worse under scale: scenarios
+with hunderds of VM are becoming not unusual.
+
+patch posted on qemu-devel, reviewd, acked and merged into maintainer's branch:
+https://github.com/stefanha/qemu/commit/f050ea639522e9dd7e501ef285a2a12709b8726a
+
+Upstream here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=e2462113b2003085ad16f15e1
+