High CPU use when guest is idle

[lkraav]

btw i couldnt immediately get my custom kernel to achieve this. must look further into it later tonight.

[mateo]

Hi folks - sounds like great progress in figuring out the issue. I'm wondering if someone can explain to me, a complete newbie to Linux and a Mac OS X Terminal dummy, whether this fix is something that I should just wait for the next version of VirtualBox to address, or whether this is something I need to implement myself inside the Ubuntu guest.

?

If the latter is the case (it requires tinkering in Ubuntu), I'd really appreciate a how-to if anyone has time.

[h1d]

It's all about seeing 30% cpu constant usage or 10% constant usage on your Mac OS X host (at least from a visible perspective).

If you don't want your OS X to take 30% all the time, go to the settings of your Ubuntu guest under Network and change the Network Device card to either of the bottom gigabit ones instead of pcnet ones and relaunch guest and it should have less constant CPU usage.

Not sure what other side effects are having either pcnet or e1000 as I'm not about to investigate at the source code level.

[h1d]

A little new finding. (not really a good news)

I went to install a Debian (etch) with minimal installation off net-inst cd iso. All goes good, and figures even without a single NIC defined in the config, now the CPU takes constant ~25% when guest Debian is sitting idle. (Same with e1000 NIC turned on or PAE option turned on. GA is installed.)

I guess some difference of kernel config or some such between Debian and Ubuntu may make a difference for Virtualbox on Mac OS X host too.

Edit:  I just upgraded that etch to lenny to see what could happen, and the CPU usage dropped to ~12% instead, mostly identical to that of Ubuntu's. Considering lenny will be the next stable pretty soon, I guess it's no biggie. The kernel got bumped from something like 2.6.18 to 2.6.25, so your custom kernel may be using something older than that to cause the high CPU issue.

[night]

Hi,

if you use the closed source version of virtual box, you can have USB Support. I used to have it enabled and have had high CPU usage.
I removed the USB support from my in 'Settings' for my guests and the cpu usage dropped a lot. From 30-50% down to 10-15%.
(On MacBook Pro 2.4GHz, Mac OS X 10.5.4)

If you don't need USB try disabling it, hopefully it helps you, too.

greetz

[amagine]

My Setup (See my SIG below) XP3 guest/ Mac OS X.5.4 Host 1.6.4 VBox

I concur that Attaching USB devices to the GUEST OS increases CPU Usage of Vbox VM.

ie.

USB Enabled = ~12-15% cpu usage VirtualBox VM on HOST
USB Enabled + 1 USB device attached = 30-35% cpu usage VirtualBox VM on HOST
USB Enabled + 2 USB devices attached = 90-100% cpu usage VirtualBox VM on HOST

DOCK usage will also climb up too 75% is using USB device results in Screen Output of large amount of USB data transfer (such as Track downloads from GPS)

These are my observations, thus far.

[qzy]

I don't have this problem. I am running xp on a mac mini. The cpu is just 5% for virtual box when vm is idle and I cannot feel it anyway.

cpu:1.83ghz
ram:1gb
os: mac os x.5.4

[TerryE]

amagine, just out of interest right click on C:\WINDOWS\system32\hal.dll, Properties=>Version=>Internal Name. This should be hal.dll. If this is something else, for example halmacpi.dll, then you missed an important step in installing Windows on VBox. This could account for your high CPU.

[amagine]

Right on, I'll have a Booh in there.
+++
hal.dll = hardware abstraction layer

Yah, it is installed in system32 folder. No halmacpi.dll that I can 'find'

All and all the XP virtual machine is very responsive and efficient, I only notice the CPU usage if I am Polling OR when I have 2 USB devices attached and downloading data from a 1.1 USB device which pulls the VM 'down' - pushes the CPU up to 100% and stalls the VM for a period of time.

[night]

amagine, just out of interest right click on C:\WINDOWS\system32\hal.dll, Properties=>Version=>Internal Name. This should be hal.dll. If this is something else, for example halmacpi.dll, then you missed an important step in installing Windows on VBox. This could account for your high CPU.

Hi, i tried to install and run WinXP without ACPI. Unfortunately it was unstable, and after some shutdowns i could't boot the image anymore.

I'll give it another try in few days and install winXP wihtout ACPI. I'll post if i encounter the same problems again.

[TerryE]

night and amagine, please read again what I wrote.

There are four different versions of hal.dll for single- and multi-processor support and for ACPI and not. The NT installation process renames them all to hal.dll so you will always and only find hal.dll in system32. It is just that the file named hal.dll will be one of four variants. The way you tell the difference is

right click on C:\WINDOWS\system32\hal.dll, Properties=>Version=>Internal Name.

The file name is not what we need; look at the name within properties. If you are loading one of the m or acpi variants then your machine will run poorly and you will need to enable ACPI to get it to work at all.

So guys, can you right click ....

[night]

Hi TerryE,

i did install another WinXP in the mean time. Now i have two, one with ACPI and one without ACPI. Both work. Both have nearly the same cpu usage while idling. (12-17% / 2CPU). They also behave similar with some more cpu usage.

Don't worry about the right click, i did right click and checked if the internal Name of hal.dll ist hal.dll or halacpi.dll.
The WinXP with ACPI has: halacpi.dll
The WinXP withou ACPI has: hal.dll

But it seems not to matter, at least for me. Seems to be an other problem, probably with the USB ?? I'm using OSE and don't use USB.

[TerryE]

Have a look at Wikipedia entries ACPI and SMP. These are advanced features to control the power usage and share processing across multiple CPU. Neither are relevant in a VBox VM since the host OS doesn any ACPI functions and the VBox VMM only emulates a single CPU. Both add extra emulation processing which you pay at each time slice and the more active devices that you have the higher the wasted overhead. You are right -- this may turn out to be a bug in the USB driver, but using anything other than the basic non-ACPI HAL is a wasted overhead.

[amagine]

Hello TerryE,

Thanks for looking over my shoulder making sure I looked prudently.

I should have mentioned that the "Internal Name" = hal.dll, that I could not find any reference to halcpi.dll anywhere in the Properties window, through all three tabs etc.

I'm not so much complaining, but feel that perhaps there may be some connection to the USB drivers in some way unforeseen in component tests. *shrug*.

I'm happy with straight up Vanilla Virtualization with any cherries on the top as bonus.