Date: Thu, 25 Aug 2005 09:00:25 -0600 From: Scott Long <scottl@samsco.org> To: Ville-Pertti Keinonen <will+freebsd-current@will.iki.fi> Cc: freebsd-current@freebsd.org, Jeremie Le Hen <jeremie@le-hen.org>, josh.carroll@psualum.com Subject: Re: On a hyperthreaded system, top and gnome system monitor only report one processor Message-ID: <430DDD09.5000403@samsco.org> In-Reply-To: <430DDAB2.1030101@will.iki.fi> References: <430D68D4.50609@drexel.edu> <430D6C0F.1070909@freebsd.org> <8cb6106e0508250035f066aa1@mail.gmail.com> <20050825134942.GO659@obiwan.tataz.chchile.org> <430DDAB2.1030101@will.iki.fi>
index | next in thread | previous in thread | raw e-mail
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. Scotthome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?430DDD09.5000403>