diff options
Diffstat (limited to 'results/classifier/111/performance')
| -rw-r--r-- | results/classifier/111/performance/1119861 | 55 | ||||
| -rw-r--r-- | results/classifier/111/performance/1228285 | 95 | ||||
| -rw-r--r-- | results/classifier/111/performance/1529173 | 69 | ||||
| -rw-r--r-- | results/classifier/111/performance/1873341 | 49 | ||||
| -rw-r--r-- | results/classifier/111/performance/1913341 | 56 | ||||
| -rw-r--r-- | results/classifier/111/performance/498417 | 69 | ||||
| -rw-r--r-- | results/classifier/111/performance/928676 | 71 |
7 files changed, 464 insertions, 0 deletions
diff --git a/results/classifier/111/performance/1119861 b/results/classifier/111/performance/1119861 new file mode 100644 index 000000000..af92ad0bf --- /dev/null +++ b/results/classifier/111/performance/1119861 @@ -0,0 +1,55 @@ +performance: 0.470 +other: 0.139 +graphic: 0.112 +semantic: 0.080 +device: 0.068 +PID: 0.023 +socket: 0.022 +vnc: 0.018 +boot: 0.016 +permissions: 0.014 +files: 0.013 +network: 0.010 +debug: 0.010 +KVM: 0.006 +performance: 0.913 +debug: 0.019 +other: 0.012 +files: 0.008 +device: 0.008 +socket: 0.007 +PID: 0.006 +semantic: 0.006 +vnc: 0.005 +graphic: 0.005 +network: 0.004 +boot: 0.003 +permissions: 0.003 +KVM: 0.002 + +Poor console performance in Windows 7 + +As part of its conformance test suite, Wine tests the behavior of the Windows console API. Part of this test involves opening a test console and scrolling things around. The test probably does not need to perform that many scroll operations to achieve its goal. However as is it illustrates a significant performance issue in QEmu. Unfortunately it does so by timing out (the tests must run in less than 2 minutes). Here are the run times on a few configurations: + + 10s - QEmu 1.4 + Q9450@2.6GHz + Windows XP + QXL + QXL driver + 8s - QEmu 1.12 + Opteron 6128 + Windows XP + QXL + QXL driver +127s - QEmu 1.12 + Opteron 6128 + Windows 7 + cirrus + vga driver +127s - QEmu 1.12 + Opteron 6128 + Windows 7 + QXL + QXL driver +147s - QEmu 1.12 + Opteron 6128 + Windows 7 + vmvga + vga driver +145s - QEmu 1.12 + Opteron 6128 + Windows 7 + vmvga + vmware driver (xpdm, no better with all graphics effects disabled) + + 10s - Metal + Atom N270 + Windows XP + GMA 950 + Intel driver + 6s - Metal + i5-3317U + Windows 8 + HD4000 + Intel driver + 3s - VMware + Q9450@2.6GHz + Windows XP + vmvga + vmware driver + 65s - VMware + Q9450@2.6GHz + Windows 7 + vmvga + vmware driver + +So when running on the bare metal all versions of Windows are about as fast. However in QEmu Windows 7 is almost 16 times slower than Windows XP! VMware is impacted too but it's still maintains a good lead in performance. + +Disabling all graphics effects did not help so it's not clear that the fault lies with Windows 7's compositing desktop window manager. Maybe it has to do with the lack of a proper wddm driver? + + + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +It does seem to be ok now. The test did get simplified to remove parts that were mostly redundant so it runs faster now. But still it now takes the same time, 7 seconds, on the VMware and QEMU Windows 7 VMs. So as far as I'm concerned this can be closed. + diff --git a/results/classifier/111/performance/1228285 b/results/classifier/111/performance/1228285 new file mode 100644 index 000000000..e78ccbafd --- /dev/null +++ b/results/classifier/111/performance/1228285 @@ -0,0 +1,95 @@ +performance: 0.216 +socket: 0.146 +other: 0.109 +semantic: 0.105 +network: 0.092 +device: 0.072 +vnc: 0.057 +PID: 0.056 +debug: 0.035 +permissions: 0.028 +graphic: 0.023 +files: 0.023 +KVM: 0.022 +boot: 0.017 +performance: 0.609 +network: 0.168 +debug: 0.112 +socket: 0.049 +device: 0.015 +boot: 0.009 +files: 0.008 +PID: 0.008 +vnc: 0.007 +other: 0.007 +semantic: 0.005 +permissions: 0.003 +graphic: 0.001 +KVM: 0.001 + +e1000 nic TCP performances + +Hi, + +Here is the context : + +$ qemu -name A -m 1024 -net nic vlan=0,model=e1000 -net socket,vlan=0,listen=127.0.0.1:7000 +$ qemu -name B -m 1024 -net nic vlan=0,model=e1000 -net socket,vlan=0,connect=127.0.0.1:7000 + +The bandwidth is really tiny : + + . Iperf3 reports about 30 Mb/sec + . NetPerf reports about 50 Mb/sec + + +With UDP sockets, there is no problem at all : + + . Iperf3 reports about 1 Gb/sec + . NetPerf reports about 950 Mb/sec + + +I've noticed this fact only with the e1000 NIC, not with others (rtl8139,virtio, etc.) +I've used the main GIT version of QEMU. + + +Thanks in advance. + +See you, +VInce + +On Fri, Sep 20, 2013 at 05:21:23PM -0000, Vincent Autefage wrote: +> Here is the context : +> +> $ qemu -name A -m 1024 -net nic vlan=0,model=e1000 -net socket,vlan=0,listen=127.0.0.1:7000 +> $ qemu -name B -m 1024 -net nic vlan=0,model=e1000 -net socket,vlan=0,connect=127.0.0.1:7000 +> +> The bandwidth is really tiny : +> +> . Iperf3 reports about 30 Mb/sec +> . NetPerf reports about 50 Mb/sec +> +> +> With UDP sockets, there is no problem at all : +> +> . Iperf3 reports about 1 Gb/sec +> . NetPerf reports about 950 Mb/sec +> +> +> I've noticed this fact only with the e1000 NIC, not with others (rtl8139,virtio, etc.) +> I've used the main GIT version of QEMU. + +It's interesting that you see good performance over -netdev socket TCP +with the other NIC models. + +I don't know what the issue would be, you'll probably need to dig +further to discover the problem. Using wireshark might be a good start. +Try to figure out where the delay is incurred and then instrument that +code to find out the cause. + +Stefan + + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/111/performance/1529173 b/results/classifier/111/performance/1529173 new file mode 100644 index 000000000..534e3ba5e --- /dev/null +++ b/results/classifier/111/performance/1529173 @@ -0,0 +1,69 @@ +performance: 0.234 +vnc: 0.105 +device: 0.090 +other: 0.085 +files: 0.072 +boot: 0.065 +PID: 0.062 +semantic: 0.061 +graphic: 0.056 +permissions: 0.049 +socket: 0.041 +KVM: 0.034 +debug: 0.030 +network: 0.014 +performance: 0.901 +debug: 0.021 +PID: 0.015 +KVM: 0.013 +files: 0.009 +other: 0.008 +semantic: 0.007 +socket: 0.006 +device: 0.005 +graphic: 0.004 +vnc: 0.003 +network: 0.003 +boot: 0.002 +permissions: 0.002 + +Absolutely slow Windows XP SP3 installation + +Host: Linux 4.3.3 vanilla x86-64/Qemu 2.5 i686 (mixed env) +Guest: Windows XP Professional SP3 (i686) + +This is my launch string: + +$ qemu-system-i386 \ +-name "Windows XP Professional SP3" \ +-vga std \ +-net nic,model=pcnet \ +-cpu core2duo \ +-smp cores=2 \ +-cdrom /tmp/en_winxp_pro_with_sp3_vl.iso \ +-hda Windows_XP.qcow \ +-boot d \ +-net nic \ +-net user \ +-m 1536 \ +-localtime + +Console output: + +warning: TCG doesn't support requested feature: CPUID.01H:EDX.vme [bit 1] +warning: TCG doesn't support requested feature: CPUID.80000001H:EDX.syscall [bit 11] +warning: TCG doesn't support requested feature: CPUID.80000001H:EDX.lm|i64 [bit 29] +warning: TCG doesn't support requested feature: CPUID.01H:EDX.vme [bit 1] +warning: TCG doesn't support requested feature: CPUID.80000001H:EDX.syscall [bit 11] +warning: TCG doesn't support requested feature: CPUID.80000001H:EDX.lm|i64 [bit 29] + +After hitting 35% installation more or less stalls (it actually doesn't but it progresses 1% a minute which is totally unacceptable). + +That was without KVM acceleration, so perhaps it's how it's meant to be. + +With KVM everything is fast and smooth. + +For integer workloads such as installing an OS you should expect TCG to be about 12x slower than KVM on average. That is on current master; note that TCG has gotten faster in the last couple of years. See a performance comparison from v2.7.0 to v2.11.0 for SPEC06 here: https://imgur.com/a/5P5zj + +I've therefore marked the report as invalid, as I don't think the aforementioned speedups will change your experience dramatically. + diff --git a/results/classifier/111/performance/1873341 b/results/classifier/111/performance/1873341 new file mode 100644 index 000000000..2b69472b5 --- /dev/null +++ b/results/classifier/111/performance/1873341 @@ -0,0 +1,49 @@ +performance: 0.154 +device: 0.151 +KVM: 0.113 +graphic: 0.110 +other: 0.109 +semantic: 0.083 +vnc: 0.054 +files: 0.040 +PID: 0.040 +socket: 0.035 +debug: 0.031 +boot: 0.030 +network: 0.026 +permissions: 0.025 +performance: 0.344 +KVM: 0.250 +debug: 0.220 +other: 0.035 +files: 0.025 +graphic: 0.020 +device: 0.019 +network: 0.018 +socket: 0.017 +semantic: 0.017 +PID: 0.015 +vnc: 0.008 +boot: 0.007 +permissions: 0.005 + +Qemu Win98 VM with KVM videocard passthrough DOS mode video is not working for most of games.. + +Hello, +im using Win98 machine with KVM videocards passthrough which is working fine, but when i try Windows 98 - Dosbox mode, there is something work with all videocards which i tried PCI-E/PCI - Nvidia, 3Dfx, Matrox. + + Often is framerate is very slow, as slideshow: +Doom 2, Blood, even for Fdisk start - i can see how its slowly rendering individual lines, or its not working at all - freeze / black screen only - Warcraft 2 demo (vesa 640x480). + + There is something wrong with it. + + Qemu 2.11 + 4.2, Linux Mint 19.3. Gigabyte Z170 MB. + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/253 + + diff --git a/results/classifier/111/performance/1913341 b/results/classifier/111/performance/1913341 new file mode 100644 index 000000000..a40b4d94f --- /dev/null +++ b/results/classifier/111/performance/1913341 @@ -0,0 +1,56 @@ +performance: 0.130 +semantic: 0.104 +other: 0.096 +files: 0.084 +device: 0.074 +permissions: 0.071 +network: 0.069 +PID: 0.068 +socket: 0.066 +graphic: 0.058 +debug: 0.053 +vnc: 0.045 +KVM: 0.041 +boot: 0.040 +performance: 0.197 +debug: 0.186 +device: 0.098 +other: 0.097 +files: 0.074 +semantic: 0.058 +network: 0.047 +PID: 0.043 +socket: 0.041 +boot: 0.038 +graphic: 0.035 +permissions: 0.031 +vnc: 0.029 +KVM: 0.025 + +Chardev behavior breaks polling based devices + +Currently in latest QEMU (9cd69f1a270235b652766f00b94114f48a2d603f at this time) the behavior of chardev sources is that when processed (before IO polling occurs), the chardev source will check the amount of space for reading. + +If it reports more than 0 bytes available to accept the read and a callback is not set, the code will set a child source connected to the QIOChannel submitted to the original source. If there's no buffer space reported, it will check for an active source, if registered it will detach this source. + +Next time the loop fires, if the buffer now reports space (most likely the guest has run, emptying some bytes from the buffer), it will setup the callback again. + +However, if we have a stupid simple device (or driver) that doesn't have buffers big enough to fit an available write when one is sent (say a single byte buffer, polled serial port), then the poll will be set, the poll will occur and return quickly, then the callback will (depending on the backend chardev used) most likely read the 1 byte it has space for from the source, push it over to the frontend hardware side, and the IO loop will run again. + +Most likely the guest will not clear this byte before the next io loop cycle, meaning that the next prepare call on the source will see a full buffer in the guest and remove the poll for the data source, to allow the guest time to run to clear the buffer. Except, without a poll or a timeout set, the io loop might now block forever, since there's no report from the guest after clearing that buffer. This only returns in a sane amount of time because often some other device/timer is scheduled which sets a timeout on the poll to a reasonable time. + +I don't have a simple submittable bit of code to replicate at the moment but connecting a serial port to a pty then writing a large amount of data, while a guest that doesn't enable the fifo spins on an rx ready register, you can observe that RX on the guest takes anywhere from 1s to forever per byte. + +This logic all occurs in chardev/char-io.c + +Fixing this can be as simple as removing the logic to detach the child event source and changing the attach logic to only occur if there's buffer space and the poll isn't already setup. That fix could cause flow control issues potentially if the io runs on the same thread as the emulated guest (I am not sure about the details of this) and the guest is in a tight loop doing the poll. I don't see that as happening but the logic might be there for a reason. + +Another option is to set a timeout when the source gets removed, forcing the poll to exit with a fixed delay, this delay could potentially be derived from something like the baud rate set, forcing a minimum time before forward progress. + +If removing the logic isn't an option, another solution is to make the emulated hardware code itself kick the IO loop and trigger it to reschedule the poll. Similar to how the non-blocking write logic works, the read logic could recognize when the buffer has been emptied and reschedule the hw on the guest. In theory this sounds nice, but for it to work would require adding logic to all the emulated chardev frontends and in reality would likely be going through the effort to remove the callback only to within a few nanoseconds potentially want to add it back. + +I'm planning to submit a patch with just outright removing the logic, but am filing this bug as a place to reference since tracking down this problem is non-obvious. + +commit f2c0fb93a44972a96f93510311c93ff4c2c6fab5 + + 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.] + diff --git a/results/classifier/111/performance/928676 b/results/classifier/111/performance/928676 new file mode 100644 index 000000000..8a9313160 --- /dev/null +++ b/results/classifier/111/performance/928676 @@ -0,0 +1,71 @@ +performance: 0.262 +device: 0.122 +graphic: 0.085 +files: 0.073 +other: 0.067 +permissions: 0.067 +vnc: 0.061 +socket: 0.059 +semantic: 0.056 +PID: 0.042 +network: 0.030 +debug: 0.030 +boot: 0.025 +KVM: 0.020 +performance: 0.282 +debug: 0.149 +files: 0.101 +other: 0.085 +PID: 0.066 +semantic: 0.064 +socket: 0.057 +device: 0.044 +KVM: 0.039 +boot: 0.027 +network: 0.026 +graphic: 0.025 +permissions: 0.019 +vnc: 0.016 + +QEMU does not support Westmere (Intel Xeon) CPU model + +Setting the CPU model to Westmere (Intel Xeon server CPU) is not possible. + +libvirt uses 'core2duo' as fallback: +https://bugzilla.redhat.com/show_bug.cgi?id=708927 + + +$ qemu -cpu ? +x86 [n270] +x86 [athlon] +x86 [pentium3] +x86 [pentium2] +x86 [pentium] +x86 [486] +x86 [coreduo] +x86 [kvm32] +x86 [qemu32] +x86 [kvm64] +x86 [core2duo] +x86 [phenom] +x86 [qemu64] + +$ qemu --version +QEMU emulator version 1.0 (Debian 1.0+dfsg-3), Copyright (c) 2003-2008 Fabrice Bellard + +An application test with high cpu load gives the timing statistics give: + + + bare metal virtual percent + +X4560 cpu 50m28s 54m0s 107% + +X5690 (westermere) 29m20s 38m0s 134% + + + +Westmere seems to be available in the latest version of QEMU: +$ qemu-system-x86_64 -cpu ? | grep Westmere +x86 Westmere Westmere E56xx/L56xx/X56xx (Nehalem-C) +==> Setting status to "Fix released" now. + |