diff options
Diffstat (limited to 'results/classifier/105/other/1847525')
| -rw-r--r-- | results/classifier/105/other/1847525 | 124 |
1 files changed, 124 insertions, 0 deletions
diff --git a/results/classifier/105/other/1847525 b/results/classifier/105/other/1847525 new file mode 100644 index 00000000..d1ce9666 --- /dev/null +++ b/results/classifier/105/other/1847525 @@ -0,0 +1,124 @@ +other: 0.968 +mistranslation: 0.966 +KVM: 0.954 +vnc: 0.952 +assembly: 0.952 +device: 0.950 +semantic: 0.949 +instruction: 0.946 +socket: 0.940 +graphic: 0.939 +network: 0.936 +boot: 0.935 + +qemu-system-i386 eats a lot of cpu after just few hours, with sdl,gl=on + +I already send this email to <email address hidden> , but I can't see it arriving in archives, so here is copy. + +Hello, all! + +I use qemu-system-i386/qemu-system_x86_64 for rebuilding Slax-like live cd/dvd. +Usually guests (with various self-compiled kernels and X stack with kde3 on top of them) +boot up normally, but if I left them to run in GUI mode for few hours - qemu process on host +started to eat more and more cpu for itself - more notiecable if I set host cpu to lowest possible +frequency via trayfreq applet (1400Mhz in my case). + +Boot line a bit complicated, but I really prefer to have sound and usb inside VM. +qemu-system-i386 -cdrom /dev/shm/CDROM-4.4.194_5.iso -m 1.9G -enable-kvm -soundhw es1370 -smp 2 -display sdl,gl=on -usb -cpu host -rtc clock=vm + +rtc clock=vm was taken from https://bugs.launchpad.net/qemu/+bug/1174654 but apparently not helping. +After just 3 hours of uptime (copied line from 'top' on host) + +31943 guest 20 0 2412m 791m 38m R 51 6.7 66:36.51 qemu-system-i38 + +I use Xorg 1.19.7 on host, with mesa git/nouveau as GL driver. But my card has not very big amount of VRAM - only 384Mb. +May be this limitation is playing some role .. but 'end-user' result was after 1-2 day of guest uptime I run into completely frozen guest +(may be when qemu was hitting 100 one core usage on host some internal timer just made guest kernel too upset/froze? + I was sleeping or doing other things on host for all this time, with VM just supposedly running at another virtual desktop - +in KDE3 + built-in compositor ....) + +I wonder if more mainstream desktop users (on GNOME, Xfce, etc) and/or users of other distros (I use self-re-compiled Slackware) +actually can see same problem? + +qemu-system-i386 --version +QEMU emulator version 4.1.50 (v4.1.0-1188-gc6f5012ba5-dirty) +but I saw same behavior for quite some time .. just never reported it in hope it will go away. + +cat /proc/cpuinfo +processor : 0 +vendor_id : AuthenticAMD +cpu family : 21 +model : 2 +model name : AMD FX(tm)-4300 Quad-Core Processor +stepping : 0 +microcode : 0x6000852 +cpu MHz : 1399.977 +cache size : 2048 KB +physical id : 0 +siblings : 4 +core id : 0 +cpu cores : 2 +apicid : 16 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb cpb hw_pstate ssbd vmmcall bmi1 arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold +bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass +bogomips : 7600.06 +TLB size : 1536 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro + +[and 3x more of the same, for 3 remaining cores] + +Gcc is Slackware 14.2's gcc 5.5.0, but I saw this with 4.9.2 too. +This might be 32-bit host problem. But may be just no-one tried to run qemu with GUI guest for literaly days? + +Host kernel is + uname -a +Linux slax 5.1.12-x64 #1 SMP PREEMPT Wed Jun 19 12:31:05 MSK 2019 x86_64 AMD FX(tm)-4300 Quad-Core Processor AuthenticAMD GNU/Linux + +I was trying newish 5.3.2 but my compilation was not as stable as this one +(I tend to change few things, like max cpu count, preemption mode, numa support .... +for more distribution-like, yet most stable and performant for me kernel) + +Kernel world is moving fast, so I'll try to recompile new 5.3.x too .... + + +I guess I should provide perf/profiler output, but for this I need to recompile qemu. +I'll try to come back with more details soon. + +Thanks for your attention and possible feedback! + +Illustration for this bug (link to screenshot): + +https://www.imgbin.net/z/9W9eVVvbll.png + +as you hopefully can see, just after less than 6 hrs of guest uptime HOST cpu is eaten at 70% by qemu-system-i386 task .. up from just 50% two hours ago! By this rate it will not survive even day of uptime.... + +this one still with me. + +qemu-system-x86_64 --version +QEMU emulator version 4.2.91 (v5.0.0-rc1-dirty) + +on 32-bit host (Slackware, but with 64-bit kernel) compiled with gcc 5.5.0 + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + |