On 1/7/2011 6:49 AM, Jeff Squyres wrote:
> My understanding is that hyperthreading can only be activated/deactivated at boot time -- once the core resources are allocated to hyperthreads, they can't be changed while running.
> Whether disabling the hyperthreads or simply telling Linux not to schedule on them makes a difference performance-wise remains to be seen. I've never had the time to do a little benchmarking to quantify the difference. If someone could rustle up a few cycles (get it?) to test out what the real-world performance difference is between disabling hyperthreading in the BIOS vs. telling Linux to ignore the hyperthreads, that would be awesome. I'd love to see such results.
> My personal guess is that the difference is in the noise. But that's a guess.
Applications which depend on availability of full size instruction
lookaside buffer would be candidates for better performance with
hyperthreads completely disabled. Many HPC applications don't stress
ITLB, but some do.
Most of the important resources are allocated dynamically between
threads, but the ITLB is an exception.
We reported results of an investigation on Intel Nehalem 4-core
hyperthreading where geometric mean performance of standard benchmarks
for certain commercial applications was 2% better with hyperthreading
disabled at boot time, compared with best 1 rank per core scheduling
with hyperthreading enabled. Needless to say, the report wasn't popular
with marketing. I haven't seen an equivalent investigation for the
6-core CPUs, where various strange performance effects have been noted,
so, as Jeff said, the hyperthreading effect could be "in the noise."