Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 5 Oct 2003 11:28:38 -0400 
From:      Don Bowman <don@sandvine.com>
To:        'Wilko Bulte' <wkb@freebie.xs4all.nl>, Kris Kennaway <kris@obsecurity.org>
Cc:        freebsd-hackers@freebsd.org
Subject:   RE: Hyperthreading slowdown
Message-ID:  <FE045D4D9F7AED4CBFF1B3B813C85337035E39E5@mail.sandvine.com>

next in thread | raw e-mail | index | archive | help
From: Wilko Bulte [mailto:wkb@freebie.xs4all.nl]
> On Sat, Oct 04, 2003 at 01:04:35PM -0700, Kris Kennaway wrote:
> > On Sat, Oct 04, 2003 at 03:20:03PM -0400, Richard Coleman wrote:
> > > Kris Kennaway wrote:
> > > >On Sat, Oct 04, 2003 at 04:39:03PM +0200, Mikulas Patocka wrote:
> > > >>I installed FreeBSD 4.9RC1 on P4 3GHz with 
> hyperthreading and I see
> > > >>drastic slowdown when kernel with hyperthreading is 
> booted. For example
> > > >>program compilation took this time:
> > > >>
> > > >>hyperthreading kernel,  make -j 1 --- 1:09
> > > >>hyperthreading kernel,  make -j 2 --- 0:42
> > > >>singlethreading kernel, make -j 1 --- 0:45
> > > >>singlethreading kernel, make -j 2 --- 0:41
> > > >>
> > > >>Compilation does very few system calls so when I 
> compile with only one
> > > >>process (-j 1), it should be as fast as with 
> singlethreading kernel. Do
> > > >>you have any idea why is it so slow?
> > > >
> > > >Do you realise that hyperthreading != a secret extra CPU 
> in your system?
> > > >
> > > >Kris
> > > 
> > > I didn't see anywhere in the message where he implied 
> that.  To me, the 
> > > interesting thing is that there is such a larger 
> difference between the 
> > > compile time for -j1 and -j2 when using hyperthreading as 
> compared to 
> > > the difference between -j1 and -j2 for a single threaded 
> kernel.  It's 
> > > over a 50% slowdown.
> > 
> > Yes, that's because (as discussed in the archives) the kernel treats
> > it like an extra, completely decoupled physical CPU and schedules
> > processes on it without further consideration.  This is 
> presumably the
> > cause of the slowdown, because it's only efficient to use 
> the virtual
> > CPU under certain workload patterns.  HTT is not magic performance
> > beans.
> 
> Right. And in addition it makes the system considerably more 
> power hungry..
> I measured both with and without SMP on my P4/2.4G HTT CPU. 

FWIW, if you set the machdep.cpu_idle_hlt=1, your power will
go down considerably (our AC inlet power dropped 0.94A @ 110V).
The performance will also go up considerably.

HTT seems to get a lot of bad press on this list, and its due
to this sysctl having the wrong default.

If you are using an intel hyperthreading (aka symmetric multi
threading) system, you should have machdep.cpu_idle_hlt=1 on.
I emailed the poster this last week, and his performance 
rose dramatically. In our applications it also is much faster
to use HTT than to have it off, since it hides the latencies
associated with memory access. His comment after enabling 
halt was:

>Thanks, that's it (maybe it should be enabled by default on HT kernels or
>written as a comment around HTT option). Now it takes 41 seconds with -j 1
>(faster than non-ht kernel because it uses -pipe) and 32 to 38 seconds
>with -j 2.
>
>Mikulas

--don



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FE045D4D9F7AED4CBFF1B3B813C85337035E39E5>