cvs commit: src/sys/amd64/amd64 mp_machdep.c src/sys/i386/i386 mp_machdep.c

[Robert Watson]

On Sat, 10 Nov 2007, Julian Elischer wrote:

> Maxim Sobolev wrote:
>> Bruce Evans wrote:
>>> Off is a good default since hyperthreading seems to be a pessimization in 
>>> most casts.
>> 
>> Well, actually it all depends on workload and scheduling. I believe ULE is 
>> expected to improve things quite a bit in scheduling department. However, 
>> even with ol'good SCHED_BSD we measured noticeable performance increase 
>> (15-25%) in CPU intensive real-world tasks with HTT enabled on 2-way SMP 
>> Xeon system. It was in 2004, both CPUs and schedules should have been 
>> improved since that time.
>
> Vicor (where I used to work) noticed recently that newer systems were 
> getting much less work done thann their older bretheren. On investigation 
> they found that it was because the newer systems had HT turned off..  Their 
> workload is a mix of FP and Int crunching in image processing and just 
> happens to be the near perfect HT workload. With 2 x HT processors (4 
> logical processors), they could get about 3.7 times the throughput of a 
> single processor in tests I did in 04 or so.
>
> However for most other loads HT turned out to be at best a wash and at worst 
> a slight loss, so having it off will help the average user I think.

This used to be the wisdom, but more recent testing has shown that HTT is at 
worst a break-even and often a performance improvement--presumably some of 
this is a result of better SMP support in FreeBSD, but some is also an 
improvement of the basic HTT technology.  A significant factor has been the 
replacement of the P4 Xeon line from Intel, which had extortionately high 
synchronization costs--more recent processors behave a lot better.  While we 
can make legitimate security arguments for/against HTT, I think the intuitive 
"but it's a bad idea anyway so it doesn't hurt to turn it off" thinking 
regarding HTT is no longer valid.  To be specific, turning off HTT may lead to 
modest or significant performance loss for our users.

Robert N M Watson
Computer Laboratory
University of Cambridge