37

As I have a Hyper-Threading capable CPU, I wonder, is it a bad idea to assign more virtual CPU cores than number of physical CPU cores as the following warning suggests:

VirtualBox Warning

Transcript:

More virtual CPUs are assigned to the virtual machine than the number of physical CPUs on the host system. This is likely to degrade performance of your virtual machine. Please consider reducing the number of virtual CPUs.

Can someone put a reasoning to this topic?

EDIT1:

The CPU in question is Intel Core i7-4700HQ, Ark Intel, CPU Benchmark

EDIT2:

Supposing, there is no obsolete HW, like HDD (instead of an SSD), and / or Low RAM (16GB here, minimum vm.swappiness, 4GB for this VM), and so on.

  • 2
    The warning is reasonably accurate, and should not be ignored unless real-time performance is unimportant, or if only a minimal (software) load will put on the virtual machine. See So what are logical cpu cores (as opposed to physical cpu cores)? – agc Nov 25 '16 at 6:21
  • As the waring says. Things might actually be faster with less CPUs in the VM. – Rui F Ribeiro Nov 25 '16 at 6:41
  • You should never go into the red line. It's ok to use 4 "cores" on a 4 actual HT-enabled cores CPU. For RAM, 50% of your RAM should do, even if the green part is beyond that. – cylgalad Nov 25 '16 at 8:56
  • In Virtualbox, "cores" are all the threads, so if you have a CPU with 4 cores and Hyperthreading, that's like 8 "cores", so you can actually set up to 4 virtual cores in one VM if you run it alone; that's what I do all the time and it works great. – cylgalad Apr 7 '17 at 7:24
  • What do I have to prove? The red line is for over 4 "cores" for me, I never go beyond, and I never run 2 VMs at the same time. If you prefer the risk of crashing your PC by giving all the CPU to the VM and you don't do anything outside the VM it may be ok. – cylgalad Apr 7 '17 at 7:31
27

Hardware / OS / Software

Host: Linux Mint 18 Cinnamon 64-bit (fully updated); Kernel version 4.4.0-47-generic

Guest: Windows 8.1 Pro 64-bit (fully updated)

Processor: Intel Core i7-4700HQ, (6MB cache, 4 physical cores, or 8 using Hyper-Threading), CPU Benchmark

VirtualBox: Version 5.1.10 r112026 (Qt5.5.1)

Guest Additions: Installed and up-to-date

Benchmark Tool #1: WinRAR version 5.40 final 64-bit

Benchmark Tool #2: VeraCrypt version 1.19 final 64-bit


Preparation

In both cases I waited after boot until the CPU, RAM, disk drive are at stable near zero-point hits.


Method

  1. Cloning the original virtual machine to have two identical ones.
  2. I have, for the second pass, since the reboot disabled Antivirus pointed out at the bottom of this answer and updated WinRAR in both cases from a Beta to the Final version.
  3. I have done the same Preparation as pointed out earlier.
  4. The virtual machine ran in foreground, without any other CPU time hungry application running, I have disabled what I could for the purpose of the test not being influenced.
  5. To include potential caching inside or outside the system, I ran the same test twice consequently. The benefit being almost none.

Results

WinRAR

  1. 4 cores => 7.5 minutes (shorter time is better)

    WinRAR with 4 cores enabled

    WinRAR with 4 cores enabled, 1.5GiB processed in 7.5 minutes.

  2. 8 cores => 4.5 minutes (shorter time is better)

    WinRAR with 8 cores enabled

    WinRAR with 8 cores enabled, 1.5GiB processed in 4.5 minutes.


VeraCrypt

  1. 4 cores => speed 2.6 GiB/s (higher speed is better)

    VeraCrypt with 4 cores enabled

    VeraCrypt with 4 cores enabled, HW-accelerated AES (AES-NI) speed 2.6 GiB/s.

  2. 8 cores => speed 3.9 GiB/s (higher speed is better)

    VeraCrypt with 8 cores enabled

    VeraCrypt with 8 cores enabled, HW-accelerated AES (AES-NI) speed 3.9 GiB/s.


Conclusion

I could run as many tests as necessary. But I figure, if these two, one of which is rather complex compression test, the second being a set of rather complex encryption tests, what would be the point.

Both of the benchmarks show a marked difference. I see no reason to believe, that their results are inaccurate, as I followed a rather rigorous preparation and method, moreover these tests have taken place in RAM to rule out I/O bottleneck. From my standpoint, the warning mentioned in the question may apply to some conditions, but certainly not all of them. Having shared with you these pretty remarkable results, I am certain for you to agree with me, that this warning probably should not be taken so seriously on modern CPUs featuring Hyper-Threading with the latest VirtualBox version. One thing for sure: Don't take me for the word and test it under your own conditions, before you decide to apply this setting permanently.

  • Did you run it on the same VM with the cores changed, or two different (but identical) VMs? If the same VM, did you try again in the other sequence afterward to rule out possible influence of guest OS caching algorithms? – Wildcard Nov 25 '16 at 13:38
  • Try to run an actual CPU burn test for the fun. – cylgalad Apr 7 '17 at 7:32
  • Something like prime95 for at least an hour. And try to browse the web on the host at the same time. As I said, it's ok if you don't do anything on the host or don't run more than one VM at a time. If it was that bad, the limit would have been enforced in Virtualbox instead of a warning. – cylgalad Apr 7 '17 at 7:38
  • Another thing you can try but it may be harder. Install a gentoo or Linux from Scratch VM, and check how things go when it's intensively compiling. Or try to build Chromium in a VM. – cylgalad Apr 7 '17 at 7:41
  • @Vlastimil totally agree. In my case I use VM for C++ compilation (which is a cpu bound task) and the only reason I got a 16-core cpu was to be able to compile faster. That warning is complete nonsense without proper explanation and leads to this wrong conclusions like "Things might actually be faster with less CPUs in the VM" – Pavel Sep 17 '17 at 17:37
15

As an OS designer I completely agree with the result of the measurements. The amount of bullshit produced elsewhere about the subject matter is unbelievable.

See the number of logical cores as the number parallel threads/processes that can be executed by the HW. That is achieved by duplicating e.g. the registers and instruction pointers of a CPU core. The CPU core itself now decides which thread (instruction pointer) to use. It will decide to use the other thread as the instruction of the current thread is not available in the cache and need to be fetched from e.g. memory or L3 cache. This mechanism will create a 10%-30% potential improvement in instructions/seconds or CPU performance.

If you run a single application with one thread, you will not be able to reap this benefit, but if you run two high load applications on e.g. an old HT Pentium, you will be able to reap the benefits. The same is true of course for applications, that have more then one thread. My Linux system has 200 threads, so some benefits dependent on the actual load are always present. All these remarks apply without virtualization.

Virtualbox only limits the number of threads that can run in parallel for each virtual machine (VM), but the host process scheduler will change the logical processor(s) and thus physical processor(s), on which the VM processes run dynamically. If you run a high load applications on a VM, the additional logical cores will give you the same benefit of 10%-30%. The load can be a single multi-threaded application or a set of different applications.

On modern systems with VT-x or AMD-V there is no performance penalty for maxing out the number of logical cores, since there is also no noticeable performance penalty for running more virtual machines at the same time. Your limit is the performance of your CPU chip, so you can't render videos on 3 VMs at the same time without slowing down each VM, because they have to share the same physical CPU.

Your host system might become irresponsive, if you render a video on a VM with all logical cores present, but you would have almost the same problem, if you did run that rendering app on your host. At least in VM you have a choice and you could solve it by limiting the max CPU load to 80%-90% or by reducing the number of cores for this reason.

0

My best two cents is to never use all cores/threads, just let one or two for host.

So in your case, give to guest a six core, never an eigth core (because you have only 8 threads on host).

If number of available threads (not to be confused with cores) on host is:

  • If < 2, better not use virtual machines at all
  • If 2, use virtual machines on mono-core mode or take a risk and use dual core guest
  • If > 2, better use a formula

For more than two threads i tend to use this formula:

  • N = Number of thread for host
  • M = Number of concurrent virtual machines i want to run (assuming equaly balance, same number of guest cores for each guest)
  • Formula=(N-1)/M if host has only 4 threads or less
  • Formula=(N-2)/M if host has more than 4 threads

My experence tells me it is much smoother and less risky to not overpass such formula limit.

Warning: It is not allowed to change number of guest cores while running the guest, but it is allowed to lower CPU usage from 100% down to 75% or also 50%, not less of guest may fail.

So sometimes i tend to give to two guests 6 six cores on a 8 thread host (the number of the formula as if only one guest instead of two guest), but limiting them to 50% of CPU speed (so both guest can use 1/2 of the time the CPU), but only when i know guests will run apps that has a bigger than one ratio of parallel, like with image compare/joint, etc.

  • 1
    You yourself had made these formulas? Or can you add citations? – Vlastimil May 11 '18 at 13:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.