WinXP SMP still VERY SLOW under VB 4.3.6

[socratis]

Back to testing. I have a WinXP number crunching program which can take advantage of multiple CPUs. Below are the results for varying number of CPUs, as well as the no IOAPIC VM. Units are in million operations per second.

VM w/o IOAPIC : 25.1
VM w IOAPIC-1 : 24.4
VM w IOAPIC-2 : 44.3
VM w IOAPIC-3 : 54.5
VM w IOAPIC-4 : 63.8 <- Number of physical cores on my machine
VM w IOAPIC-5 : 69.4
VM w IOAPIC-6 : 76.1
VM w IOAPIC-7 : 82.7
VM w IOAPIC-8 : 88.1 <- Number of logical cores on my machine
VM w IOAPIC-9 : 86.0
VM w IOAPIC-10 : 83.9
VM w IOAPIC-12 : 66.8

Performance scales nicely up to the number of CPUs suggested by VBox, which incidentally is also the max. number of logical cores on my system. This was expected, since there's no IO involved. Anything above MaxLogicalCores is expected to have reduced performance. Note that in the graph below, 0 #_of_CPUs is the VM where IO/APIC is not enabled.

Next up; HD benchmarking...

PS. I use my WinXP guest for number crunching, so I'm not personally affected by the IO/APIC - ACPI_enabled WinXP combination. I just took it up to me to provide some hard numbers in a (semi)scientific analysis.

XPwIOAPIC.CPU.png (26.05 KiB) Viewed 7295 times

[michaln]

I (and lots of others) have posted reproduction scenarios many times;

You seem to suffer from the common misconception that if you see some problem, everyone else must necessarily be seeing it too. If only it were so simple.

I don't really get i twhy it would be so much better to send logs and add trac records, when it is so easy to reproduce:

Sigh.

I clearly failed to get this point across, but I'll try again anyway: The expected performance greatly depends on the host hardware and VM configuration. It matters whether software or hardware virtualization is used, and in the latter case, how capable the hardware is. All that information is in the VBox.log file. I just exhausted my monthly quota of "please attach your VBox.log file" requests so I'll stop right here.

[socratis]

I'm lost... how does ACPI fix it?
So ACPI is used in both cases. APIC is used in the multiprocessor case but not the other one.

OK, here's what I discovered. If you start a new XP installation with the default template (4.3.6), it's a single processor with IO/APIC disabled. Windows XP installs a kernel_module(?)/HAL(?) that is described as "Advanced Configuration and Power Interface (ACPI) PC". This is not multi-processor aware.

If you set 2 or more processors in VBox, VBox automatically enables IO/APIC. The next time you reboot, Windows detects new hardware and installs a different kernel_module/HAL that is described simple as "ACPI", which is multi-processor aware. This is what's causing the problems.

If you manually change the kernel_module/HAL to the "Advanced Configuration and Power Interface (ACPI) PC" (the "old" one), WinXP no longer has any performance issues, but it also sees only one CPU. Not what you were expecting.

I've attached logs in previous posts as well as benchmarks that show this behavior. As I said, boot times are affected greatly, raw CPU performance is not. Next I will try some HD benchmarking and post the results. I'm expecting a big performance hit...

[ChipMcK]

You all seem to forget that Windows XP was designed/created in environment of a single cpu.

Kludging it into a multiple cpu environment is not a good idea

[mpack]

You all seem to forget that Windows XP was designed/created in environment of a single cpu.

Not quite. It was designed in the days when your typical desktop CPU had one core. However multi-cpu boards did exist, and I'm pretty sure NT supported them since NT4 days.

[mpack]

The next time you reboot, Windows detects new hardware and installs a different kernel_module/HAL that is described simple as "ACPI"

Which "Windows" are you referring to? E.g. I'm reasonably sure XP doesn't ever replace the HAL, you have to do that manually. Search for HALu on this site.

[socratis]

@mpack
OK, maybe it's not the HAL, that's why I had a (?) next to it. Maybe a kernel module? A dll? I don't know... Look at the picture in my previous post to see which part it affects. In there (in the Device Manager) it talks about a "driver". But on the other hand, everything in there is a driver.

@ChipMcK
As mpack said, Windows XP can and does run fine with multiple CPUs. The problem is the implementation of the VBox IO/APIC subsystem and how it interacts with WinXP (so far I haven't seen anything else affected). I've got the data to show for it and two days of investigation.

If it's not going to be addressed because of a technical or other reasons, that's OK. We just need an acknowledgement from someone (devs?) that, "Yes, there is a problem at this and that point. No gonna fix it, tough luck". But, so far there have been many many reports and nobody seemed inclined to do a little bit more research...

[mpack]

If not the HAL then I can't think of what else this could refer to. I know that when I last bought a new PC, and P2P'd my old XP-Pro retail image to it, the old ACPI HAL did not change to a multi-cpu HAL by itself. AFAIK, the short story is that XP doesn't expect the motherboard architecture to suddenly change. Whatever it found when first installed is what it expects to see forever. To what extent this is true I'm not sure.

[socratis]

You know it would really help if only there was a program that presented you with a virtual machine to try this theory easily without messing with your actual system...

[thanar]

You all seem to forget that Windows XP was designed/created in environment of a single cpu.

Kludging it into a multiple cpu environment is not a good idea

Creating a new winXP VM under Parallels Desktop with multiple CPUs does NOT produce any such issues. It was also working fine under VirtualBox 4.2.12; so there's something that changed in the way 4.3.x works with I/O when there are multiple CPUs available that breaks things badly.

Hope the information socratis provided will help resolve this bug. There IS a bug, it just may be a bit difficult to locate.

[mpack]

You know it would really help if only there was a program that presented you with a virtual machine to try this theory easily without messing with your actual system...

I've used HALu in XP VMs several times, though generally it's only required after a P2V since for normal VMs it's easier to get the recipe right to begin with.

However, the fact that it can be done and that I've done it doesn't prove that it was necessary.

[socratis]

It was also working fine under VirtualBox 4.2.12; so there's something that changed in the way 4.3.x works with I/O when there are multiple CPUs available that breaks things badly.

Can you please verify that? I went as low as 3.1.x and the issue was present. Similar times for booting. I also tried 4.2.12 just like you said and the latest 4.2.20 and the issue was present [1].

IO/APIC present vs not_present has the same behavior. It has nothing to do with multiple CPUs (of course if you want multiple CPUs, you have to have IO/APIC enabled).

Code: Select all

VBox   Revision    With    Without
3.1.8  (61349)     19      11
3.2.18 (89859)     23      11
4.0.20 (89853)     21      11
4.1.28 (89849)     20      11
4.2.20 (90983)     23      12
4.3.4  (91027)     18      10
4.3.6  (91406)     13       9

So, at least from my experience, this is NOT a regression. Maybe it was like that since the beginning of time...

[1] I had to disable VT-x in the guest to make it work on the 4.2 series otherwise I would get a critical error during installation (something which I don't remember happening when I was on the 4.2 series).

[Ramshankar]

Unfortunately, comparing VT-x vs non-VT-x performance in this case (i.e. in finding a possible regression between 4.2.x and 4.3.x) is comparing apples to oranges.

[socratis]

comparing VT-x vs non-VT-x performance is comparing apples to oranges.

No, no, no... I wasn't comparing VT-x vs. non-VTx. I was comparing IO/APIC vs. non-IO/APIC. In the 4.2 case (only) I couldn't get the setup to continue unless both guests (APIC vs. non-APIC) had their VT-x disabled.

[thanar]

It was also working fine under VirtualBox 4.2.12; so there's something that changed in the way 4.3.x works with I/O when there are multiple CPUs available that breaks things badly.

Can you please verify that? I went as low as 3.1.x and the issue was present. Similar times for booting. I also tried 4.2.12 just like you said and the latest 4.2.20 and the issue was present [1].

Just did a couple of tests myself and looks like you're right; issue exists in 4.2.12 as well, guess I do not remember correctly. Sorry for that.