On a hyperthreaded system, top and gnome system monitor only report one processor

Scott Long scottl at samsco.org
Thu Aug 25 15:00:48 GMT 2005


Ville-Pertti Keinonen wrote:
> Jeremie Le Hen wrote:
> 
>> It is commonly accepted that HyperThreading decreases performances
>> on FreeBSD systems.  Both 4BSD and ULE consider dual-core processors
>> as two separates processors.  This is a problem because dual-core
>> processors use the same L2 cache for their logical processors (IIRC)
>> and therefore we cannot schedule whatever threads on them without
>> taking care of not invalidating the cache too much.
> 
> 
> You seem to be confusing dual-core and HyperThreading.
> 
> Dual-core (and multi-core in general) is "real" SMP; it may or may not 
> share various levels of caches (but then again, historically so can SMP 
> on machines with multiple separately packaged processors), but there are 
> definitely multiple independent CPUs.
> 
> HyperThreading (and various non-Intel forms of SMT) doesn't just share 
> caches, but there's basically just one CPU with multiple sets of 
> registers.  Instructions from several threads can be "in flight" 
> simultaneously in the (single) execution core, in order to make better 
> use of the resources available...sometimes, for certain types of code.

Hyperthreading can often be a good thing when you are dealing with code
that is itself multithreaded and has lots of pipeline stalls.  C++ and
Java apps (being that most JVM's are written in C++ and use the native
threading of the OS) are a good example of this.  While one thread
stalls waiting for a lots of memory fetches to figure out a virtual
method dispatch, another thread can come in and do useful work.
Unfortunately, the Unix kernel does match this profile very well, nor
does a lot of traditional Unix apps that are written as discrete
process-oriented C state machines instead of monolithic threaded C++.
In Windows where all the world is MFC and .NET and whatnot, it has some
measurable gains.  Having a scheduler that aggressively optimizes for
this case is also a good thing, and indeed neither FreeBSD scheduler
does this very well, though the ULE scheduler has some foundation pieces
to possibly do it in the future.

Scott


More information about the freebsd-current mailing list