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

[Bruce Evans]

On Sat, 10 Nov 2007, Robert Watson wrote:

> On Sat, 10 Nov 2007, Julian Elischer 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 
>> ...
>> 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.

My comment was based on old wisdom and recent benchmarking of building
kernels on nosedive and freefall.  When nosedive became freefall, build
times seemed to go up by about 10%.  (The benchmarks were not very
careful since I can't control the machine, and had to estimate the
pessimization from gcc-3 -> gcc-4.  The scheduler also changed from
4BSD to ULE.  The machine is still lightly loaded).  User times certainly
went up by about 100%, which suggests that each logical processor is
waiting half the time for the other on the same core, and makes user
times incomparable with the non-HTT case.  But freefall is a P4 Xeon,
so most non-recent [Athlon] processors also behave better than it.

Bruce