4 vCPUs configured, only 1 physical CPU ever in use. Why?

[yann]

I'm running a Ubuntu machine on VirtualBox 5.2.2. This box is a build environment, I want it to be able to compile on multiple cores. So I configured the box with 4 vCPUs. However, the following benchmark suggest only 1 physical CPU is ever in use:

Code: Select all

root@vagrant-box:~# stress-ng --cpu 4 -t 30
stress-ng: info:  [1532] dispatching hogs: 4 cpu

Meanwhile, the output of 'top' shows:

Code: Select all

1548 root      20   0   43168   6908   4068 R 25.4  0.2   0:01.54 stress-ng-cpu                  
1549 root      20   0   43168   6908   4068 R 25.4  0.2   0:01.54 stress-ng-cpu                  
1547 root      20   0   43168   6908   4068 R 23.9  0.2   0:01.54 stress-ng-cpu                  
1550 root      20   0   43168   6908   4068 R 23.9  0.2   0:01.54 stress-ng-cpu

If 4 CPUs were in use, 100% should show up, not 25%. This measurement (and compile times) suggests only 1 physical CPU is ever in use, even if 4 are configured.

Any suggestion as to why this happens? More info is available in VBox.log. You help is appreciated!

[mpack]

Giving a guest access to 4 (or whatever) cores doesn't mean that it has to use them. That's entirely up to the guest software. I wouldn't expect a compiler to make use of multiple cores - for a start you'd need a make system that can handle multiple make steps in parallel - and handling their associated dependencies sounds tricky. IMHO this just isn't a good application for multiple cores.

[Perryg]

Use htop instead. It will show a graphical as well as a percent of CPU utilization.

stress-ng --cpu 2 -t 30

stress_test.png (46.02 KiB) Viewed 2127 times

[yann]

Giving a guest access to 4 (or whatever) cores doesn't mean that it has to use them. That's entirely up to the guest software. I wouldn't expect a compiler to make use of multiple cores - for a start you'd need a make system that can handle multiple make steps in parallel - and handling their associated dependencies sounds tricky. IMHO this just isn't a good application for multiple cores.

Being able to compile a C/C++ application on multiple cores is of paramount importance to keep quick compile cycles. Anyway, your answer unfortunately does not address the question.

[Perryg]

@yann,
I have shown that it is possible to use 100% of all CPUs assigned to the guest. What makes yours different in the fact that it fails? The log does not show any real issue. I see you are using vagrant and one must wonder if that is a factor, although I have no way to test this as I don't use it.

[yann]

Use htop instead. It will show a graphical as well as a percent of CPU utilization.
stress-ng --cpu 2 -t 30

The attachment stress_test.png is no longer available

Thanks for your input! Here is how it displays on my system:

htop.png (27.47 KiB) Viewed 2053 times

According to this and /proc/cpuinfo, I have only one processor on the VM! I need now to figure out why this is so, even if I configured it with 4 processors:

VBoxConfig.png (21.52 KiB) Viewed 2053 times

Any idea?

[Perryg]

Not really. As I said the only difference between yours and mine is vagrant. I would see if running it independently from vagrant allow it to utilize all of the cores.

Note: Keep in mind that additional cores in a guest do have a substantial overhead due to the way Virtualizers work So even if you achieve all cores and it may show 400% with 4 cores, the results will be far less.

[yann]

After comparing my VM settings with another one, I found out the cause of my problem: the cpu hotplug function was enabled.
After disabling this function, the number of CPUs in my VM are as configured. See also:
viewtopic.php?f=8&t=50174

[mpack]

Anyway, your answer unfortunately does not address the question.

On the contrary, I believe it did. Specifically the part (my very first sentence) where I said "Giving a guest access to 4 (or whatever) cores doesn't mean that it has to use them". That comment directly addressed and answered the question asked in the topic title. I believe the answer was also correct, because as far as I can see, everything else discussed here has been about how to change how the guest makes use of available cores.