Virtualization: vCPU pinning with Hyperthreading Host CPU

kvm-virtualizationpinningvcpuvirtualization

I'm using KVM/libvirt on a Linux server with Core i7-2600 CPU, which has the following CPU topology (1 Socket, 4 Cores, 8 Threads):

Physical | Logical
---------+--------
Core 0   | 0, 4
Core 1   | 1, 5
Core 2   | 2, 6
Core 3   | 3, 7

I usually run 3 virtual machines on this host, each with 2 virtual CPUs. In order to improve performance by keeping caches hot, I'd like to pin the vCores of the VMs to fixed host cores.

The question now is the mapping of VM cores to host cores, considering the fact that the host CPU uses Hyperthreading:

Option 1: One VM per physical host core

VM1: logical cores 1, 5
VM2: logical cores 2, 6
VM3: logical cores 3, 7

This way, the two virtual cores of a VM would be mapped to sibling hyperthreads on the host CPU. Guest code would profit from cache locality, as the two host cores share some caches.

But given the fact that two hyperthreads also share some functional units, they would slow down each other under computational load.

Option 2: Distributed VM cores

VM1: logical cores 1, 2
VM2: logical cores 3, 5
VM3: logical cores 6, 7

This mapping has the advantage that, if a VM experiences computational load on both of its two virtual cores, this load is mapped on two separate physical cores on the host. If no other VM is under load at that moment, the former could use two physical cores, instead of only one with Option 1.

The VMs all run mainly web services (Nginx, MySQL, PHP-FPM), so I know the question is of rather theoretical nature – but still I'd like to know.

Best Answer

You may be overthinking this.

The manual assignment of cores here could actually result in lower performance. In the VMware world, we don't do this unless there are very specific requirements, but for the workload and applications you've described, it's not necessary. Let KVM schedule things and be done. If in doubt, get more cores and sockets. But CPU isn't going to be the limiting factor in such a small deployment.

Related Topic