linux-kernel - Re: How to detect multi-core and/or HT-enabled CPUs in 2.4.x and 2.6.x kernels

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20061227152240.GC10953@minantech.com>
Date:	Wed, 27 Dec 2006 17:22:40 +0200
From:	glebn@...taire.com (Gleb Natapov)
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	knobi@...bisoft.de, linux-kernel@...r.kernel.org
Subject: Re: How to detect multi-core and/or HT-enabled CPUs in 2.4.x and 2.6.x kernels

On Wed, Dec 27, 2006 at 04:13:00PM +0100, Arjan van de Ven wrote:
> The original p4 HT to a large degree suffered from a too small cache
> that now was shared. SMT in general isn't per se all that different in
> performance than dual core, at least not on a fundamental level, it's
> all a matter of how many resources each thread has on average. With dual
> core sharing the cache for example, that already is part HT. Putting the
> "boundary" at HT-but-not-dual-core is going to be highly artificial and
> while it may work for the current hardware, in general it's not a good
> way of separating things (just look at the PowerPC processors, those are
> highly SMT as well), and I suspect that your distinction is just going
> to break all the time over the next 10 years ;) Or even today on the
> current "large cache" P4 processors with HT it already breaks. (just
> those tend to be the expensive models so more rare)
> 
If I run two threads that are doing only calculations and very little or no
IO at all on the same socket will modern HT and dual core be the same
(or close) performance wise?

--
			Gleb.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/