Page 4 of 4

Re: High CPU using Windows 10 Version 1803 as host and guest

Posted: 29. Mar 2019, 07:12
by mhanor
At least some of us can reproduce it, just by launching the VM.

Re: High CPU using Windows 10 Version 1803 as host and guest

Posted: 29. Mar 2019, 07:16
by socratis
As you very well know, that is not helpful, not helpful at all. We need to figure out "why" some of you can reproduce it, what's the common denominator. A "me too" is of little help/added value...

And as long as the "some of us" doesn't include a developer, good luck finding the source of the problem and fixing the issue...

Re: High CPU using Windows 10 Version 1803 as host and guest

Posted: 29. Mar 2019, 22:44
by mhanor
As far as I know, you are not a dev, so it's not critical that you can't reproduce it.
I'm still waiting for feedback from a dev here. I can reproduce it, but I don't know how to investigate it, even with the OSE debug build.

Re: High CPU using Windows 10 Version 1803 as host and guest

Posted: 29. Mar 2019, 23:53
by socratis
mhanor wrote:As far as I know, you are not a dev, so it's not critical that you can't reproduce it.
True, it's not critical, but it's important; tells you that on a freshly installed installation it's not reproducible. But it is also true that the developers can't reproduce it AFAIK.

Re: High CPU using Windows 10 Version 1803 as host and guest

Posted: 3. May 2019, 10:34
by t-quadrat
Hi.

I am experiencing the same problem on a Mac OS X host (Mac mini mid 2011, 2 GHz Intel Core i7 4-core) with all up to the latest VirtualBox versions 6.0.6 and a pure fresh install of Windows 10 (1809). I did a lot of reading and found that KVM on Linux had similiar issues with Windows 10 guests and that those are related to the (emulation or not) of high performes HPET timers. (You can google for "high cpu load for windows 10 guests when idle 44531" and look for a hit on proxmox, currently it is hit #1; sorry I am not able to post URLS here).

I did some experimenting and found out that the load that my Mac OS X experiences indeed depends on how timers are being emulated. There is a tool called "WinTimerTester_1.1" around (google for "try-changing-hpet-settings-to-improve-your-pcs-performance"). In a boilerplate fresh install of Win 10 with Virtualbox standard settings for Win 10, that testing tools shows 10.000000 MHz for my case. Through various iterations of chipset settings (PIIX vs. ICH9) on Virtualbox and "bcdedit /set useplatformclock false" or "bdedit /set useplatformclock true" I was able to create scenarios in which values lower or higher than 10.0000 MHz were shown. Whenever I got such a scenario, the problem was gone (host was consuming less than 10 % when guest was idle), whereas, in the 10.00000 MHz scenario, I experience between 50 and 150 percent of load when the guest is totally idle.

However, sadly, after some time (probably after the latest updates were drawn), I am back at the 10.000 MHz scenario irrespective of which chipset or bcdedit parameter I use, and correspondingly, my host is again pegged as soon as I start the VM.

I was able to alleviate the situation a bit by using Win32 rather than Win64, allocating 2 CPUs to the guest and doing other miscellaneous optimizations, but I won't get below 50 percent host usage even for an idle Win32 install as long as the HPET timers are being emulated at 10.00000 MHz.

An idea that occurred to me is that this might be related to Spectre somehow, since not everyone experience the problem and my host is affected by Spectre so the host OS probably applies patches for it.

Be that as it may, the bug is caused by Virtualbox emulating HPET timers which are not needed for most scenarios (i.e. everything that is not games or video streaming). There should definitely be an option in Virtualbox to switch of said HPET timer emulation.

To confirm that this can be fixed on the host side, I migrated my VM to Parallels, and in Parallels, all is good (no high load on the host is caused when VM is idle) with the very same VM.

I hope that this post includes enough pointers for the developers to figure out what is going on.

TIA.

Re: High CPU using Windows 10 Version 1803 as host and guest

Posted: 8. Jun 2019, 22:46
by Lumimies
I think I found a solution so embarrassingly obvious that I'm almost afraid to post it.

I've been dealing with this high CPU utilization problem for several months and I've tried everything suggested here. I finally found a solution that worked: empty the recycle bin in the Windows guest. I had hundreds of files in mine across a half dozen attached drives. I usually ignore my recycle bin because I have it turned off on my guest's C: drive and usually hit SHIFT-delete when deleting a file. But some automated test processes that create and delete test files had been just sending stuff to the recycle bin.

Anyway, my CPU usage had been pegged at 100% no matter what processes were running and at idle. Now it's the much more typical 2-3 % when idle.

I'm very curious if this solves the problem for anyone else.

Re: High CPU using Windows 10 Version 1803 as host and guest

Posted: 9. Jun 2019, 14:39
by BerlinUser
I had only two files in the bin and deleting them didn't make a different. But good for you ;)

Re: High CPU using Windows 10 Version 1803 as host and guest

Posted: 26. Jun 2019, 12:05
by quadrater
The problem of having constant (50%+) core load on OS X host with a Windows 10 64-bit guest can be resolved successfully by enabling HPET for the guest VM in VirtualBox. Using the VBoxMange tool in the Terminal:

Code: Select all

$ cd /Applications/VirtualBox.app/ContentsMacOS/
$ ./VBoxManage list vms
"Windows10" {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX}
$ ./VBoxManage modifyvm "Windows10" --hpet on
It might be achievable by disabling HPET inside Windows as an option. It might even be the better solution. Any ideas on how?

Re: High CPU using Windows 10 Version 1803 as host and guest

Posted: 26. Jun 2019, 13:21
by socratis
@quadrater,
I appreciate your post that aims to help people, but... You're on an OSX host, and the title is clearly labelled as "... Windows ... as host and guest". So, unfortunately your solution does not apply as is to the rest of the people in this thread.

Second, you definitely don't need to go to the "/Applications/VirtualBox.app/ContentsMacOS/" and do a "./VBoxManage". You simply open a terminal and do a "VBoxManage", since it's installed in "/usr/local/bin/VBoxManage" that's in the path. Simpler no? ;)

Re: High CPU using Windows 10 Version 1803 as host and guest

Posted: 17. Aug 2019, 17:44
by maxchen
quadrater wrote:The problem of having constant (50%+) core load on OS X host with a Windows 10 64-bit guest can be resolved successfully by enabling HPET for the guest VM in VirtualBox. Using the VBoxMange tool in the Terminal:

Code: Select all

$ cd /Applications/VirtualBox.app/ContentsMacOS/
$ ./VBoxManage list vms
"Windows10" {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX}
$ ./VBoxManage modifyvm "Windows10" --hpet on
It might be achievable by disabling HPET inside Windows as an option. It might even be the better solution. Any ideas on how?
Great!
This works on Windows LTSC 2019 x64 guest on Linux host.
Now the ICH9 method has a slighter higher CPU than this method. and I like this 'hpet on' solution!
After a full day's test, with two vm running the same app inside, I found that ICH9 is half CPU of 'PIIX3+ hpet on' solution. I will stick to the ICH9 solution

Re: High CPU using Windows 10 Version 1803 as host and guest

Posted: 18. Nov 2020, 21:27
by gwiesenekker
Hi,

On an Ubuntu 20.04 host Windows 10 guest CPU usage when idle (10% CPU usage) seems to have greatly improved with the 6.1.16 release. It used to be 50-100% all the time and none of the workarounds mentioned in this or other threads worked for me, but now it is around 20%.

Regards,
GW

Re: High CPU using Windows 10 Version 1803 as host and guest

Posted: 14. Feb 2021, 22:51
by triatic
I came across this myself, when a Windows 10 guest VM is idle, the Windows 10 host CPU is locked at 50%. After giving the VM two cores instead of one, the host was able to idle at around 5% CPU.

Thanks for the suggestion.