Hyper-V and Hyper-threading: On or off?

Question

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!

Answer 1

According to Windows IT Pro, you want to leave it on:

• John Savill, WindowsITPro.com, 2009-03-08, Q. Does Hyper-Threading affect Hyper-V? (Archived here.)

A. 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.

Answer 2

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

Newer chips have larger and smarter caches so this is less of a 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 certainly 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 larger cache you can get the better. RAM truly is MUCH slower than CPUs - just not NEAR as bad as disk drives.

NOTE: What you are reading that says "turn off" was found regarding the chips that were single core with Hyper-Threading - For example this was official answer back in the day (2005/2006?) - http://www.VirtualServerFAQ.com/tiki-index.php?page=VirtualServerHostDualCore

Steve Radich http://www.VirtualServerFAQ.com

Answer 3

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.

Answer 4

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.

Answer 5

Hyperthreading: Wow, free processors!

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.

Copied from: http://blogs.technet.com/b/exchange/archive/2013/05/06/ask-the-perf-guy-sizing-exchange-2013-deployments.aspx