qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Bug 1847525] [NEW] qemu-system-i386 eats a lot of cpu after just few hours, with sdl, gl=on
@ 2019-10-09 19:43 Andrew Randrianasulu
  2019-10-09 19:48 ` [Bug 1847525] " Andrew Randrianasulu
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: Andrew Randrianasulu @ 2019-10-09 19:43 UTC (permalink / raw)
  To: qemu-devel

Public bug reported:

I already send this email to qemu-discuss@nongnu.org , 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!

** Affects: qemu
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1847525

Title:
  qemu-system-i386 eats a lot of cpu after just few hours,  with
  sdl,gl=on

Status in QEMU:
  New

Bug description:
  I already send this email to qemu-discuss@nongnu.org , 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!

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1847525/+subscriptions


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug 1847525] Re: qemu-system-i386 eats a lot of cpu after just few hours, with sdl, gl=on
  2019-10-09 19:43 [Bug 1847525] [NEW] qemu-system-i386 eats a lot of cpu after just few hours, with sdl, gl=on Andrew Randrianasulu
@ 2019-10-09 19:48 ` Andrew Randrianasulu
  2020-04-01 12:11 ` Andrew Randrianasulu
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: Andrew Randrianasulu @ 2019-10-09 19:48 UTC (permalink / raw)
  To: qemu-devel

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....

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1847525

Title:
  qemu-system-i386 eats a lot of cpu after just few hours,  with
  sdl,gl=on

Status in QEMU:
  New

Bug description:
  I already send this email to qemu-discuss@nongnu.org , 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!

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1847525/+subscriptions


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug 1847525] Re: qemu-system-i386 eats a lot of cpu after just few hours, with sdl, gl=on
  2019-10-09 19:43 [Bug 1847525] [NEW] qemu-system-i386 eats a lot of cpu after just few hours, with sdl, gl=on Andrew Randrianasulu
  2019-10-09 19:48 ` [Bug 1847525] " Andrew Randrianasulu
@ 2020-04-01 12:11 ` Andrew Randrianasulu
  2020-04-01 14:56 ` Alex Bennée
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: Andrew Randrianasulu @ 2020-04-01 12:11 UTC (permalink / raw)
  To: qemu-devel

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

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1847525

Title:
  qemu-system-i386 eats a lot of cpu after just few hours,  with
  sdl,gl=on

Status in QEMU:
  New

Bug description:
  I already send this email to qemu-discuss@nongnu.org , 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!

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1847525/+subscriptions


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug 1847525] Re: qemu-system-i386 eats a lot of cpu after just few hours, with sdl, gl=on
  2019-10-09 19:43 [Bug 1847525] [NEW] qemu-system-i386 eats a lot of cpu after just few hours, with sdl, gl=on Andrew Randrianasulu
  2019-10-09 19:48 ` [Bug 1847525] " Andrew Randrianasulu
  2020-04-01 12:11 ` Andrew Randrianasulu
@ 2020-04-01 14:56 ` Alex Bennée
  2021-04-22  7:41 ` Thomas Huth
  2021-06-22  4:18 ` Launchpad Bug Tracker
  4 siblings, 0 replies; 6+ messages in thread
From: Alex Bennée @ 2020-04-01 14:56 UTC (permalink / raw)
  To: qemu-devel

** Tags added: tcg

** Tags removed: tcg
** Tags added: kvm

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1847525

Title:
  qemu-system-i386 eats a lot of cpu after just few hours,  with
  sdl,gl=on

Status in QEMU:
  New

Bug description:
  I already send this email to qemu-discuss@nongnu.org , 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!

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1847525/+subscriptions


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug 1847525] Re: qemu-system-i386 eats a lot of cpu after just few hours, with sdl, gl=on
  2019-10-09 19:43 [Bug 1847525] [NEW] qemu-system-i386 eats a lot of cpu after just few hours, with sdl, gl=on Andrew Randrianasulu
                   ` (2 preceding siblings ...)
  2020-04-01 14:56 ` Alex Bennée
@ 2021-04-22  7:41 ` Thomas Huth
  2021-06-22  4:18 ` Launchpad Bug Tracker
  4 siblings, 0 replies; 6+ messages in thread
From: Thomas Huth @ 2021-04-22  7:41 UTC (permalink / raw)
  To: qemu-devel

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.


** Changed in: qemu
       Status: New => Incomplete

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1847525

Title:
  qemu-system-i386 eats a lot of cpu after just few hours,  with
  sdl,gl=on

Status in QEMU:
  Incomplete

Bug description:
  I already send this email to qemu-discuss@nongnu.org , 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!

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1847525/+subscriptions


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug 1847525] Re: qemu-system-i386 eats a lot of cpu after just few hours, with sdl, gl=on
  2019-10-09 19:43 [Bug 1847525] [NEW] qemu-system-i386 eats a lot of cpu after just few hours, with sdl, gl=on Andrew Randrianasulu
                   ` (3 preceding siblings ...)
  2021-04-22  7:41 ` Thomas Huth
@ 2021-06-22  4:18 ` Launchpad Bug Tracker
  4 siblings, 0 replies; 6+ messages in thread
From: Launchpad Bug Tracker @ 2021-06-22  4:18 UTC (permalink / raw)
  To: qemu-devel

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
       Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1847525

Title:
  qemu-system-i386 eats a lot of cpu after just few hours,  with
  sdl,gl=on

Status in QEMU:
  Expired

Bug description:
  I already send this email to qemu-discuss@nongnu.org , 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!

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1847525/+subscriptions


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2021-06-22  5:23 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-09 19:43 [Bug 1847525] [NEW] qemu-system-i386 eats a lot of cpu after just few hours, with sdl, gl=on Andrew Randrianasulu
2019-10-09 19:48 ` [Bug 1847525] " Andrew Randrianasulu
2020-04-01 12:11 ` Andrew Randrianasulu
2020-04-01 14:56 ` Alex Bennée
2021-04-22  7:41 ` Thomas Huth
2021-06-22  4:18 ` Launchpad Bug Tracker

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).