With the new Xeon CPUs supporting Hyper-threading, what is the current wisdom with regard to using it (or not) on a Hyper-V host machine?

I was originally under the impression that turning it on in a virtual host environment could be detrimental as the 'extra' CPUs were not true cores. However I've also read (unconfirmed) comments along the lines of MS doing some hard work to get Hyper-V running well in a Hyper-threading environment.

Does anyone have any solid information or experience in this regard? Cheers!

5 Answers
5

The old problem with Hyper Threading in Virtual Server 2005, without getting overly technical, is the CPU cache was being poisioned, i.e. it was caching almost nothing because the context of what was happening on each thread was unrelated - causing them to compete for the on chip cache.

Newer chips have larger and smarter caches so this is less problem.

Is it ideal to have on or off? That really depends on workload, if both threads happen to be running the same VM and the same task then it would almost certinaly be a BIG advantage to have on. If they were doing unrelated things with a lot of random RAM I/O (several different VMs for example) it would cause only half the chip's cache to be available to each which in theory could be slower - In reality it rarely is anymore.

If you have older generation chips though you may want to check the chip cache sizes - In virtualization the largest cache you can get the better - Ram truly is MUCH slower than CPUs - just not NEAR as bad as disk drives.

The new four-core Intel Core i7
processor enables hyper-threading,
which splits each processor core into
two virtual cores to (potentially)
improve performance.

The concern with Hyper-V and
hyper-threading is that you assign a
number of processor cores to each
virtual machine (VM). Imagine that you
assign one processor each to two guest
VMs from the Hyper-V management
console, thinking that each is going
to use a separate core. What if the
hypervisor assigns each of the VMs to
the same physical core, with each
getting a virtual core? You'd
potentially get lousy performance and
three physical cores not doing much,
where you'd have liked each VM to get
its own physical core.

Fortunately, this isn't the case.
Microsoft has done a lot of work
around Hyper-Threading and Hyper-V.
Essentially, while Hyper-Threading
will aid performance sometimes, it
will never hurt performance, so
Hyper-Threading should be enabled.

Programs that are aware of hyperthreading are able to distinguish between a physical core and a logical (virtual) core, and allocate resources accordingly.

Hyperthreading decreases the cost of context-switching by allowing the states of two processes to be stored at any given time, instead of just one state at a time. Context-switching is typically considered to be very expensive, because you have to load the entire state of a process into the CPU. This means that if you have a CPU-intensive process running, the hyperthreaded CPU can frequently switch between that process and others without incurring much of a performance hit.

The advantage of running virtual servers is that you can create a large pool of resources which can be allocated to different servers on the fly, as needed. This includes reallocating CPU cores and balancing the load across all the available cores. If the hypervisor doesn't know the difference between a physical core and a logical core, then you're right--some physical cores may sit idle while others are pegged at 100% CPU utilization while both of their logical cores are competing for CPU time. However, if the hypervisor is able to tell the difference between physical and logical cores, it will try to balance the CPU load across the physical CPUs before allocating multiple processes to two logical cores that belong to the same physical core.

I haven't studied the issue in detail, but Microsoft does not recommend using hyperthreading with Exchange 2010 due to "capacity planning and monitoring" issues. You might want to test your own workloads before choosing one configuration or the other.

Turn it off. While modern implementations of simultaneous multithreading (SMT), also known as hyperthreading, can absolutely improve CPU throughput for most applications, the benefits to Exchange 2013 do not outweigh the negative impacts. It turns out that there can be a significant impact to memory utilization on Exchange servers when hyperthreading is enabled due to the way the .NET server garbage collector allocates heaps. The server garbage collector looks at the total number of logical processors when an application starts up and allocates a heap per logical processor. This means that the memory usage at startup for one of our services using the server garbage collector will be close to double with hyperthreading turned on vs. when it is turned off. This significant increase in memory, along with an analysis of the actual CPU throughput increase for Exchange 2013 workloads in internal lab tests has led us to a best practice recommendation that hyperthreading should be disabled for all Exchange 2013 servers. The benefits don’t outweigh the negative impact.

I'm confused; why are you mentioning exchange? the question is about impact to hyperv. And actually the paragraph below the copied on goes on to say hyperthreading doesn't affect a virtualized exchange server, if I'm reading it right.
–
AndyFeb 24 at 23:47