Hyperthreading (HTT or MT in Intel parlance) is primarily a way to exhaust the execution unit by soaking up any remaining idle cycles. For a processor like the Xeon, there are 2 ports (or AS registers in Intel parlance) available to the same execution unit. When HTT is disabled, only one AS register is accessible to the OS run-queue, so scheduling works the same way as it does for a single CPU with time-slicing. When HTT is ENabled, the OS has to know how to schedule work onto both AS registers. These now act like 1-deep thread buffers. Provided different applications are appropriately threaded (and that's a big assumption and may not work---as GB discovered), one app's threads can be scheduled onto to one of the AS buffers (say AS0), while another app's threads can be scheduled onto the other AS buffer (say AS1). When a thread stalls on A0, the exec unit would normally become idle, but with HTT on, the exec unit can service the AS1 buffer until the AS0 becomes ready again. Actually, Intel does not tell us what the exact scheduling discipline is inside the Xeon. This is all well and good if you're on AS0, but not so wonderfull if you're on AS1 because you spend a lot of time waiting for A0 to stall. Moreover, from the standpoint of capacity analysis for SERVERS using Xeon parts, the OS is fooled into thinking the 2 ports AS0 and AS1 represent 2 *virtual* CPUS or VPUs which potentially offer twice the CPU capacity of a non-HTT CPU, i.e., 200%. In reality, this 200% capacity cannot be realized because the physical exec unit is generally more than 50% busy. Best case controlled measurements show that the exec unit only has about 25% idle cycles (1/4) available for register AS1, and therefore one never sees more than 150% (virtual) capacity consumed. This has led sys admins and capacity planners on a wild goose chase looking for the remaining 50% virtual cycles (1/4) that are not really there. A similar effect is also seen in Meso-VMs such as VMWare and Xen. This is also described in more detail in Gunther's paper.

Dear RocketRoo, thank you for your clarification. Although I drew the correct conclusion from Gunther's paper, I did not fully grasp the details. For us in Labs this means that when we transfer color technology into products we have to make sure we make full use of concurrency and the engineers can fully understand it. Fortunately there are still a few gray-haired people here and we stand a good chance to beat the competition.

Welcome. Here are some more links on virtualization that may be of interest to you and your group. http://www.kernelthread.com/publications/virtualization/ gives an introductory overview to VMs and Herb Sutter's Dr. Dobbs article http://www.gotw.ca/publications/concurrency-ddj.htm explaining how we fell off the Moore's law curve and why new tools for *concurrent programming* are required for multicores. This point of view got the attention of Bill Gates.