Date: Tue, 21 Sep 2010 20:52:31 +0300 From: Andriy Gapon <avg@freebsd.org> To: Jung-uk Kim <jkim@freebsd.org> Cc: jeff@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly Message-ID: <4C98F0DF.1000801@freebsd.org> In-Reply-To: <4C7F5F90.3030407@icyb.net.ua> References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C77F6D6.9020402@icyb.net.ua> <201008271536.08773.jkim@FreeBSD.org> <201009011426.26111.jkim@FreeBSD.org> <4C7F5F90.3030407@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
on 02/09/2010 11:25 Andriy Gapon said the following: > on 01/09/2010 21:26 Jung-uk Kim said the following: >> On Friday 27 August 2010 03:36 pm, Jung-uk Kim wrote: >>> [3] AMD is working on an SMT-capable CPU (code-named Bulldozer) and >>> my patch won't work on them. If anyone has a Bulldozer sample, >>> please look into it. >> >> I checked AMD website today and found out a new CPUID Spec. Rev. 2.34 >> was just released: >> >> http://support.amd.com/us/Embedded_TechDocs/25481.pdf >> >> They have added CPUID 0x8000001d and 0x8000001e to detect topology, it >> seems. Also, CPUID 0x80000001 %ecx bit 22 (TopologyExtensions) tells >> you whether the above CPUID functions are supported. >> >> Interesting... > > Yeah, I've heard that they are adding SMT capabilities in "Bulldozer" > processors, so I guess they have to change CPU topology detection indicators. The above comment by me is almost nonsense :) I looked at the document with better attention and I think that what the new way does is better/provides proper support for discovering non-uniform topologies based on APIC IDs of the cores. BTW, I am reading that AMD Bulldozer CPU package will consist of modules, which in turn will consist of cores. When a "core" would be something in between current notion of core and current notion of hardware thread (SMT/HTT/whatever). The Bulldozer cores will have independent arithmetic units and L1 caches, but shared FPU, L2, fetch+decode and some other elements; L3 cache is per package (shared by all "modules"). -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C98F0DF.1000801>