[ILUG] 2.6 Kernel + Hyperthreading

[Bryan O'Donoghue]

> The second downside is that threads might start fighting over the 
> caches. This
> can be a particular problem if it gets to the stage where each thread is 
> evicting
> the other's data every few instructions. This can result in a massive 
> slowdown,
> and a net throughput of far less then a single thread would get.


Sounds like you're saying that there is a potential for a HT CPU to 
switch context more often. If that is 'generally' true, then yes, I 
think you're right, HT wouldn't be so great, if it's generally not the 
case then, HT still sounds like a win.
> So in the best case, hyperthreading gives you twice the instruction 
> throughput,
> with no slowdown on either thread relative to it running alone. In the 
> worst case,
> it halves the size and associativity of your cache, and halves the size 
> of the
> re-order buffer, for a massive slowdown, even if there are two threads 
> running.
> So, basically, it depends on what the workload is.

Hmm, that sounds a little non-deterministic, so in reality it sounds 
like the only .. 'real' way to find out how application(x) will perform 
under a high system load, is to benchmark it.

I think for the upcoming release of Server software, I try out a 
multiprocess binary mcpu=pentium4 compiled with a 2.6.8.1 smp/ht enabled 
and without it enabled and see if there is any meaningful performance 
increase/decrease... then maybe make an excel spreadsheet... to show net 
increases, if they exist... marketing people love those !