Hyperthreading

Needs Refactor Mixes Glossary, FAQ & HowTo elements

Hyperthreading FAQ

What is hyperthreading?

Hyper-threading is the Intel technology name, and commonly known name, for the Computing concept known as simultaneous multithreading. AMD have an equivalent technology known as Cluster Multi-threading.

Hyperthreading is a technology designed to improve the computational performance of superscalar processors. The basic idea is that each core is split into multiple threads, each of which behave as a separate processor as far as the OS is concerned, but which share a significant portion of the resources with other threads on the same core.

A simple example which illustrates the point

Statistically, 1 in 6 instructions are memory accesses. Memory (RAM) is getting slower and slower in comparison to processor cycles. When a processor needs to do a memory read, it must sit around waiting, which is bad for performance. With hyperthreading, the processor can be waiting for a memory read for one thread at the same time it is also executing instructions from the other thread. Therefore, the overall throughput of instructions is higher, even though the two threads are sharing the processor resources.

The more complicated explanation

SMT is designed to exploit Thread Level Parallelism to help reduce instruction dependences. With Out Of Order execution, being able to fill the re-order buffer with instructions from two independent threads means that the average number of instruction dependences are halved. This means that dispatch unit has, on average, twice as many instructions to choose from, increasing the likelyhood that every single execution unit is performing useful work, rather than waiting for the dependent instructions to be completed. Overall, this statistically increases the processors instruction throughput.

Is Xen hyperthreading aware?

The short answer is, "yes".

The long answer is that Xen is able to understand the CPU topology of both Intel Hyperthreads and AMD execution units, and pass this information on to the Xen scheduler. Xen has three available schedulers, which can be selected at boot time with a Xen command-line option. The default scheduler, the Credit1 scheduler, is HT-aware and will avoid scheduling on two sibling threads if there are idle cores available.

The other two schedulers, the old SEDF scheduler, the experimental general purposeCredit2 scheduler, and the new and experimental real-time scheduler RTDS are not HT-aware. There are plans to make Credit2 HT-aware (see Credit2 Scheduler Development). There are plans on investigating how to make RTDS exploit HT better, without loosing the capability of providing real-time guarantees. There are no plans to make the SEDF scheduler HT-aware (there is no further development happening on SEDF alltoghether, actually). If you're using SEDF, RTDS or Credit2, you may want to consider disabling hyperthreading.

Should I enable hyperthreading?

In theory, for software that is HT-aware, enabling HT should never hurt, and should only help. However, people have experienced situations where enabling hyperthreading results in signficantly worse performance than with it disabled. This may be due to many factors, including increased cache footprint, or quirks in the microarchitectural implementation of the particular processor.

We at xen-devel mailing list would like to know about these so we can fix them. The ones that existed for some time were the lack of PV aware locking mechanism in Linux kernels. That has since been fixed for both HVM (3.11 and later) and PV (2.6.32 and later) - and are enabled by CONFIG_PARAVIRT_SPINLOCK enabled.

NB that because the Xen Credit1 scheduler is HT-aware, guest OS software does not need to be HT-aware.

So if you are able to make an accurate benchmark for the workload you expect to run, try it with HT and without, and do what's best.

If you're not able to run a benchmark, and you're using the default Xen scheduler, go ahead and enable HT; but if you encounter performance problems, try disabling it and see if it helps.