* [Bug 1794285] Re: 100% Host CPU usage while guest idling
[not found] <153787868402.2071.3904469903390825954.malonedeb@wampee.canonical.com>
@ 2020-11-12 6:27 ` Thomas Huth
2021-01-12 4:17 ` Launchpad Bug Tracker
1 sibling, 0 replies; 2+ messages in thread
From: Thomas Huth @ 2020-11-12 6:27 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 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/1794285
Title:
100% Host CPU usage while guest idling
Status in QEMU:
Incomplete
Bug description:
Hi,
We have an appliance that runs a FreeBSD guest on a Yocto-based host via qemu-system-x86_64.
Everything functions fine however the host uses n00% of the CPU (where n = #smp) and RAM allocated to it whilst the 1 guest is sat nearing idle.
Host:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4406 root 20 0 16.7g 16g 26m S 500 53.0 17958:38 qemu-system-x86
Guest:
CPU 0: 0.0% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.6% idle
CPU 1: 0.0% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.6% idle
CPU 2: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
CPU 3: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
CPU 4: 0.4% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.6% idle
Mem: 43M Active, 4783M Inact, 1530M Wired, 911M Buf, 9553M Free
Swap: 3072M Total, 3072M Free
I have logged this with the appliance vendor and received the response:
"This is expected behaviour and you will see the same in any case where a Guest OS runs over a Host OS.
Host here has 5 CPUs and it has assigned all of them to Guest.
Since the Host is not being shared by any Guest OS; you will always see the 500% (or the 5 CPUs) given to qemu-system-x86.
I do see the same in lab and is very much expected"
This feels fundamentally wrong to me.
I'm somewhat limited by what can be tested due to the nature of this being an appliance rather than a mainstream distro.
I'm looking for feedback that I can use to push the vendor into
investigating this issue.
Versions below.
Many thanks,
Gareth
Host:
Linux 204a-node 3.10.100-ovp-rt110-WR6.0.0.31_preempt-rt #1 SMP Fri
Aug 3 01:59:01 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux
Qemu:
QEMU emulator version 1.7.2, Copyright (c) 2003-2008 Fabrice Bellard
Command:
(Vendor identifying information has been removed)
/usr/bin/qemu-system-x86_64 \
-name REMOVED \
-S \
-machine pc-i440fx-1.7,accel=kvm,usb=off \
-m 16384 \
-realtime mlock=on \
-smp 5,sockets=5,cores=1,threads=1 \
-uuid 76277b29-3bd4-4dd4-a705-ed34d6449d6d \
-nographic \
-no-user-config \
-nodefaults \
-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/REMOVED.monitor,server,nowait \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc \
-no-shutdown \
-boot strict=on \
-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x17 \
-netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=23 \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=REMOVED,bus=pci.0,addr=0x11 \
-netdev tap,ifname=tap1,script=/etc/vehostd/XXX-em3-ifup,id=hostnet1,vhost=on,vhostfd=24 \
-device virtio-net-pci,netdev=hostnet1,id=net1,mac=REMOVED,bus=pci.0,addr=0x12 \
-netdev tap,ifname=tap2,script=/etc/vehostd/REMOVED-em4-ifup-SUMMIT,id=hostnet2,vhost=on,vhostfd=25 \
-device virtio-net-pci,netdev=hostnet2,id=net2,mac=REMOVED,bus=pci.0,addr=0x1c \
-netdev tap,ifname=tap3,script=/etc/vehostd/REMOVED-em4-re-re-ifup,id=hostnet3,vhost=on,vhostfd=26 \
-device virtio-net-pci,netdev=hostnet3,id=net3,mac=REMOVED,bus=pci.0,addr=0x1d \
-chardev pty,id=charserial0 \
-device isa-serial,chardev=charserial0,id=serial0 \
-chardev tty,id=charserial1,path=/dev/ttyS1 \
-device isa-serial,chardev=charserial1,id=serial1 \
-chardev tty,id=charserial2,path=/dev/ttyS2 \
-device isa-serial,chardev=charserial2,id=serial2 \
-chardev tty,id=charserial3,path=/dev/ttyS3 \
-device isa-serial,chardev=charserial3,id=serial3 \
-device i6300esb,id=watchdog0,bus=pci.0,addr=0x10 \
-watchdog-action reset \
-object rng-random,id=rng0,filename=/dev/random \
-device virtio-rng-pci,rng=rng0,max-bytes=1024,period=2000,bus=pci.0,addr=0x1e \
-smbios type=0,vendor="INSYDE Corp.",version=REMOVED,date=11/03/2017,release=1.00 \
-smbios type=1,manufacturer=REMOVED,product=REMOVED,version=REMOVED,serial=VF-NET \
-device REMOVED-pci,host=0000:1c:00.0 \
-device kvm-pci-assign,host=0000:00:14.0 \
-device pci-hgcommdev,vmindex=0,bus=pci.0,addr=0x16 \
-drive file=/REMOVED/REMOVED-current.img,if=none,id=drive-virtio-disk0,format=raw,cache=directsync,aio=native \
-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x13,drive=drive-virtio-disk0,id=virtio-disk0,config-wce=off,x-data-plane=on,bootindex=1 \
-drive file=/REMOVED/REMOVED-var-config.img,if=none,id=drive-virtio-disk1,format=raw,cache=directsync,aio=native \
-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x15,drive=drive-virtio-disk1,id=virtio-disk1,config-wce=off,x-data-plane=on,bootindex=-1 \
-drive file=/REMOVED/REMOVED-aux-disk.img,if=none,id=drive-ide0-0-1,format=raw,cache=directsync,discard=unmap \
-device ide-hd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=-1 \
-drive file=/REMOVED/images/0/REMOVED-platform.img,if=none,id=drive-ide1-0-1,format=raw,cache=directsync,discard=unmap \
-device ide-hd,bus=ide.1,unit=1,drive=drive-ide1-0-1,id=ide1-0-1,bootindex=-1 \
-msg timestamp=on
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1794285/+subscriptions
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Bug 1794285] Re: 100% Host CPU usage while guest idling
[not found] <153787868402.2071.3904469903390825954.malonedeb@wampee.canonical.com>
2020-11-12 6:27 ` [Bug 1794285] Re: 100% Host CPU usage while guest idling Thomas Huth
@ 2021-01-12 4:17 ` Launchpad Bug Tracker
1 sibling, 0 replies; 2+ messages in thread
From: Launchpad Bug Tracker @ 2021-01-12 4:17 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/1794285
Title:
100% Host CPU usage while guest idling
Status in QEMU:
Expired
Bug description:
Hi,
We have an appliance that runs a FreeBSD guest on a Yocto-based host via qemu-system-x86_64.
Everything functions fine however the host uses n00% of the CPU (where n = #smp) and RAM allocated to it whilst the 1 guest is sat nearing idle.
Host:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4406 root 20 0 16.7g 16g 26m S 500 53.0 17958:38 qemu-system-x86
Guest:
CPU 0: 0.0% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.6% idle
CPU 1: 0.0% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.6% idle
CPU 2: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
CPU 3: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
CPU 4: 0.4% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.6% idle
Mem: 43M Active, 4783M Inact, 1530M Wired, 911M Buf, 9553M Free
Swap: 3072M Total, 3072M Free
I have logged this with the appliance vendor and received the response:
"This is expected behaviour and you will see the same in any case where a Guest OS runs over a Host OS.
Host here has 5 CPUs and it has assigned all of them to Guest.
Since the Host is not being shared by any Guest OS; you will always see the 500% (or the 5 CPUs) given to qemu-system-x86.
I do see the same in lab and is very much expected"
This feels fundamentally wrong to me.
I'm somewhat limited by what can be tested due to the nature of this being an appliance rather than a mainstream distro.
I'm looking for feedback that I can use to push the vendor into
investigating this issue.
Versions below.
Many thanks,
Gareth
Host:
Linux 204a-node 3.10.100-ovp-rt110-WR6.0.0.31_preempt-rt #1 SMP Fri
Aug 3 01:59:01 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux
Qemu:
QEMU emulator version 1.7.2, Copyright (c) 2003-2008 Fabrice Bellard
Command:
(Vendor identifying information has been removed)
/usr/bin/qemu-system-x86_64 \
-name REMOVED \
-S \
-machine pc-i440fx-1.7,accel=kvm,usb=off \
-m 16384 \
-realtime mlock=on \
-smp 5,sockets=5,cores=1,threads=1 \
-uuid 76277b29-3bd4-4dd4-a705-ed34d6449d6d \
-nographic \
-no-user-config \
-nodefaults \
-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/REMOVED.monitor,server,nowait \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc \
-no-shutdown \
-boot strict=on \
-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x17 \
-netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=23 \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=REMOVED,bus=pci.0,addr=0x11 \
-netdev tap,ifname=tap1,script=/etc/vehostd/XXX-em3-ifup,id=hostnet1,vhost=on,vhostfd=24 \
-device virtio-net-pci,netdev=hostnet1,id=net1,mac=REMOVED,bus=pci.0,addr=0x12 \
-netdev tap,ifname=tap2,script=/etc/vehostd/REMOVED-em4-ifup-SUMMIT,id=hostnet2,vhost=on,vhostfd=25 \
-device virtio-net-pci,netdev=hostnet2,id=net2,mac=REMOVED,bus=pci.0,addr=0x1c \
-netdev tap,ifname=tap3,script=/etc/vehostd/REMOVED-em4-re-re-ifup,id=hostnet3,vhost=on,vhostfd=26 \
-device virtio-net-pci,netdev=hostnet3,id=net3,mac=REMOVED,bus=pci.0,addr=0x1d \
-chardev pty,id=charserial0 \
-device isa-serial,chardev=charserial0,id=serial0 \
-chardev tty,id=charserial1,path=/dev/ttyS1 \
-device isa-serial,chardev=charserial1,id=serial1 \
-chardev tty,id=charserial2,path=/dev/ttyS2 \
-device isa-serial,chardev=charserial2,id=serial2 \
-chardev tty,id=charserial3,path=/dev/ttyS3 \
-device isa-serial,chardev=charserial3,id=serial3 \
-device i6300esb,id=watchdog0,bus=pci.0,addr=0x10 \
-watchdog-action reset \
-object rng-random,id=rng0,filename=/dev/random \
-device virtio-rng-pci,rng=rng0,max-bytes=1024,period=2000,bus=pci.0,addr=0x1e \
-smbios type=0,vendor="INSYDE Corp.",version=REMOVED,date=11/03/2017,release=1.00 \
-smbios type=1,manufacturer=REMOVED,product=REMOVED,version=REMOVED,serial=VF-NET \
-device REMOVED-pci,host=0000:1c:00.0 \
-device kvm-pci-assign,host=0000:00:14.0 \
-device pci-hgcommdev,vmindex=0,bus=pci.0,addr=0x16 \
-drive file=/REMOVED/REMOVED-current.img,if=none,id=drive-virtio-disk0,format=raw,cache=directsync,aio=native \
-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x13,drive=drive-virtio-disk0,id=virtio-disk0,config-wce=off,x-data-plane=on,bootindex=1 \
-drive file=/REMOVED/REMOVED-var-config.img,if=none,id=drive-virtio-disk1,format=raw,cache=directsync,aio=native \
-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x15,drive=drive-virtio-disk1,id=virtio-disk1,config-wce=off,x-data-plane=on,bootindex=-1 \
-drive file=/REMOVED/REMOVED-aux-disk.img,if=none,id=drive-ide0-0-1,format=raw,cache=directsync,discard=unmap \
-device ide-hd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=-1 \
-drive file=/REMOVED/images/0/REMOVED-platform.img,if=none,id=drive-ide1-0-1,format=raw,cache=directsync,discard=unmap \
-device ide-hd,bus=ide.1,unit=1,drive=drive-ide1-0-1,id=ide1-0-1,bootindex=-1 \
-msg timestamp=on
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1794285/+subscriptions
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2021-01-12 4:29 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <153787868402.2071.3904469903390825954.malonedeb@wampee.canonical.com>
2020-11-12 6:27 ` [Bug 1794285] Re: 100% Host CPU usage while guest idling Thomas Huth
2021-01-12 4:17 ` Launchpad Bug Tracker
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.