Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Dec 2008 21:25:27 +0100
From:      Ivan Voras <ivoras@freebsd.org>
To:        freebsd-questions@freebsd.org
Subject:   Re: Status of hyperthreading in FreeBSD
Message-ID:  <giot3p$naq$1@ger.gmane.org>
In-Reply-To: <11167f520812211526h55a56a91ue4c06c02a170f439@mail.gmail.com>
References:  <200812202039.NAA10290@lariat.net> <494D5B32.50806@gmail.com> <11167f520812211526h55a56a91ue4c06c02a170f439@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF99E5472C57462DD0B52F6D2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Sam Fourman Jr. wrote:
>> as far as i know, just enabling smp will allow ht to function. also, i=
 don't
>> know if intel changed ht in the new atom processor, they could have.
> is FreeBSD's smp special in some way that it would be the exception to
> the following statement.
> I know there was a lot of changes made in the new ULE2 scheduler maybe
> that is why?
>=20
> /*
> Hyper-threading relies on support in the operating system as well as
> the CPU. Conventional multiprocessor support is not enough to take
> advantage of hyper-threading.[1] For example, even though Windows 2000
> supports multiple CPUs, Intel does not recommend that hyper-threading
> be enabled under that operating system.
> */
>=20
> I found this in wikipedia at the following link
> http://en.wikipedia.org/wiki/Hyper-threading

Yes, system respond variously to hyperthreading but it's mostly in two
areas:

a) Granularity of locking - systems with "big locks" like FreeBSD's
Giant was when HTT was new don't scale well in multi-CPU configurations
("logical" CPUs) and simply using HTT can expose and increase these
inefficiencies. Modern FreeBSD locking is "good enough" for 8 cores in
7.x and it's improving in 8.x.

b) Behaviour in multi-core (or multi-CPU) case when individual CPUs or
cores support HTT. This is a scheduler issue - if the scheduler isn't
aware that some logical CPU's are "fake" and some are not (i.e. if it
treats all of them equally) it could move processes or threads from one
CPU or CPU core to another when it would be much better to move it from
one "fake" (hyperthreaded) CPU to another within the same "real" CPU.

There are more similar issues here, but none of them (including those I
described) are applicable to Atom since a) locking in FreeBSD is good
enough for it in recent releases (even in 6.x) and b) there are only two
"fake" logical CPUs and they really can be treated equally.

Now, with Nehalem design (i7) the system can have a quad-core CPU
(actually, several of those) with each core supporting hyperthreading. A
system with 16 logical CPUs (2 x quadcore x HTT) isn't really strange
any more. The scheduler knows about HTT, so the issues under "a)" are
much more noticable.



--------------enigF99E5472C57462DD0B52F6D2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklP97cACgkQldnAQVacBciN0gCfXWIxegNpLrbl5meIi3pj4dmt
GwsAnjLjB9Kk/KSVYWOZQAoAql0szZEV
=Kxp5
-----END PGP SIGNATURE-----

--------------enigF99E5472C57462DD0B52F6D2--




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