Hyperthreading: Difference between revisions

From Xen
Jump to navigationJump to search
No edit summary
Line 35: Line 35:


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.
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.
NB that because the Xen Credit1 scheduler is HT-aware, guest OS software does not need to be HT-aware.

Revision as of 15:34, 21 November 2014


Icon todo.png 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 older SEDF scheduler, and the experimental Credit2 scheduler, are not HT-aware at the time of this writing. There are plans to make Credit2 HT-aware. There are no plans to make the SEDF scheduler HT-aware. If you're using SEDF or Credit2, it's probably a good idea to disable 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.