Opened 15 years ago
Last modified 10 years ago
#4392 closed defect
Huge IO-APIC/guest SMP overhead with 32 bits guests — at Version 17
Reported by: | rafael | Owned by: | |
---|---|---|---|
Component: | VMM/HWACCM | Version: | VirtualBox 3.0.6 |
Keywords: | Cc: | ||
Guest type: | other | Host type: | other |
Description (last modified by )
Symptoms are high CPU usage while running e.g. 32 bits Windows XP/2000 guests with IO-APIC enabled.
Current status:
- fixed for AMD-V in VirtualBox 3.0.6 (requires 3.0.6 guest additions to be installed)
- fixed for VT-x, but only if the Intel CPU supports 64 bits (leaves out Core Solo/Duo); fixed in SVN (Nov 3rd 2009)
- Solaris/OpenSolaris guests have similar issues, but a kernel fix is underway.
Does not apply to:
- 64 bits guests
- 32 bits Windows Vista or Windows 7
Change History (18)
comment:1 by , 15 years ago
comment:2 by , 15 years ago
Summary: | windows xp VM extremely slow when AMD-v is enable with 2 cpu → huge IO-APIC/guest SMP overhead with 32 bits guests (AMD-V only) |
---|
Known problem and mentioned in the manual. 32 bits guests are extremely slow with the IO-APIC enabled on AMD cpus. Will be fixed in a future release.
comment:3 by , 15 years ago
I can confirm this behavior on 3.0.2 on AMD Phenom, Mandriva 2009.1. I can also confirm that changing the HAL on the guest VM to Advanced Configuration and Power Interface (ACPI) PC, changing the VM properties to disable IO-APIC, single vCPU. The guest then runs quickly and without problems - but of course, single vCPU. Is there any roadmap for a fix?
The exact same VM runs fine with multiple vCPU and IOAPIC on Intel VT-x, what's the problem with AMD-V ?
comment:4 by , 15 years ago
It's being worked on. Intel provides an optimization feature for APIC TPR access. AMD does not, so I have fix it myself.
comment:5 by , 15 years ago
Similar statements also apply to VMs running Standard PC HAL compared with MPS Multiprocessor HAL. Switching to Standard speeds it up very much with the IOAPIC turned off in the VM settings.
Do we have a possible timeline for a fix, either a whole new version of VB3 incorporating AMD-friendly technology, or a patch to 3.0.2 ?
comment:6 by , 15 years ago
Summary: | huge IO-APIC/guest SMP overhead with 32 bits guests (AMD-V only) → huge IO-APIC/guest SMP overhead with 32 bits guests (AMD-V only) -> fixed in SVN/3.0.6 |
---|
Fixed in 3.0.6, but only after you've installed the 3.0.6 guest additions.
comment:7 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:8 by , 15 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Thanks for the good work on this bug. I will be testing it as soon as I can get my hands on 3.0.6.
Can I please ask you to regression-test this fix against Windows XP 64-bit Edition on AMD-V [3.0.4 crashes when Nested Paging is on, machine occasionally aborts without warning or logging an error when Nested Paging is off]. Host is 32-bit Mandriva 2009 and 2008.
comment:9 by , 15 years ago
It's not AMD-V only; my VT-x does it too, even with 3.0.6 Guest Additions installed. (See attachment.)
Windows 2000 SMP with Ubuntu 9.0.4 64-bit VT-x.
comment:10 by , 15 years ago
Description: | modified (diff) |
---|---|
Summary: | huge IO-APIC/guest SMP overhead with 32 bits guests (AMD-V only) -> fixed in SVN/3.0.6 → Huge IO-APIC/guest SMP overhead with 32 bits guests |
Version: | VirtualBox 3.0.0 → VirtualBox 3.0.6 |
mike: please don't mention unrelated problems in this defect. If you still see this xp64 abort with 3.0.6, then open another defect with a proper description and VBox.log.
greerga: your Intel CPU doesn't support the APIC access optimization. I intend to enable the same fix once we get more feedback about AMD-V.
follow-up: 13 comment:11 by , 15 years ago
Description: | modified (diff) |
---|
comment:12 by , 15 years ago
Component: | other → VMM/HWACCM |
---|
comment:13 by , 15 years ago
Replying to sandervl73:Point taken about 64-bit, I will keep testing that and raise a new issue for it.
However... my testing of 3.0.6 with XP 32-bit on AMD-V has shown that it's better - and it's worse. It's better - when you choose a guest ACPI Multprocessor HAL or ACPI Uniprocessor HAL, it runs without taking half an hour to boot up and flatlining one or two CPU cores at 100%. Most of the time. However today it went back to behaving like the un-patched 3.0.4 problem. I fixed this by running sudo /etc/init.d/vboxdrv restart . Clearly something in the VirtualBox drivers can revert to the old behavior given some [unknown] circumstances.
If you build your guest with the Advanced Power Configuration Interface (ACPI) HAL [i.e. no IOAPIC, as was required on 3.0.4 to work], it runs, but not as quickly as it used to on 3.0.4. So the fix has crippled non-IOAPIC but has not completely raised the performance level of IOAPIC-based configurations.
The typical performance issue is that the SysInternals Process Explorer is showing that System and Services.exe are together taking 6% or more all the time, even with dual 2.3GHz vCPUs. This is way short of physical machine performance. So the system has a performance draining wait loop somewhere inside it, meaning that activities like Windows Installer take far longer to complete than expected unless you intervene with Process Explorer and raise the process priority to "High".
It's a shame - this so nearly worked. The fact is that 3.0.4 with IOAPIC disabled and one vCPU massively outperforms 3.0.6 with dual vCPUs, which seems counter-intuitive.
Also I have had numerous aborts when Guest Additions 3D Acceleration is enabled.
comment:14 by , 14 years ago
Just getting myself on the Cc: list (couldn't find another way). Just ignore.
comment:15 by , 14 years ago
Description: | modified (diff) |
---|
comment:16 by , 14 years ago
Description: | modified (diff) |
---|
comment:17 by , 14 years ago
Description: | modified (diff) |
---|
noticed the following, if I disable the IOAPIC and set VCPU to 1, install goes fine and fast ...