<?xml version="1.0" encoding="UTF-8"?>
<!-- Generated on Thu, 24 May 2012 22:20:59 -0700 -->
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <atom:link href="http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/feed/" rel="self" type="application/rss+xml" />
    <title>Intel Software Network Comments Feed</title>
    <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration</link>
    <description></description>
    <language>en-us</language>
    <item>
      <title>By Gary Schaps</title>
      <description><![CDATA[ 
Revealing the password required to extract files from &quot;topology_enumeration_07082008.zip&quot; would certainly make it more user friendly.  Or, am I missing something?
 ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-192</link>
      <pubDate>Wed, 06 Aug 2008 14:29:02 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-192</guid>
    </item>
    <item>
      <title>By Intel Software Network Support</title>
      <description><![CDATA[ 
Hello - the zip file has been replaced with a new, non-encrypted zip file.  We apologize for the error.
 ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-196</link>
      <pubDate>Thu, 07 Aug 2008 16:02:02 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-196</guid>
    </item>
    <item>
      <title>By Igor Levicki</title>
      <description><![CDATA[ 
I would very much apreciate if Intel updated AP-485 to include CPUID leaf 0xB definition in more detail. I hate reverse-engineering someone else's code.
 ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-249</link>
      <pubDate>Fri, 12 Sep 2008 12:08:22 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-249</guid>
    </item>
    <item>
      <title>By shihjong kuo</title>
      <description><![CDATA[ 
You can also look up the definition of CPUID leaf 0BH fields in the CPUID instruction reference pages of Vol 2A.
 ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-253</link>
      <pubDate>Mon, 15 Sep 2008 19:02:33 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-253</guid>
    </item>
    <item>
      <title>By CQ Tang</title>
      <description><![CDATA[ 
I don&#39;t believe that the way to determine the cache topology is correct.

I have a machine whith two packages, two die on each package, and two core on 
each die, the two core on a die share a L2 cache.

p0-p7 are the OS processor number, p0,p2,p4,p6 are on the first package, p0 and p4 are
on the same die and share a L2 cache, but your code shows that p0 and p2 share a L2 cache,

I looked the CPUID specification, there is no relation between cache hierarchy and APIC id.

I don&#39;t know how core ID is assigned to each core, and use to construct APIC id

In my two package, two die, two core case, how is core ID assigned to each core ?

Thanks for email reply



 ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-7866</link>
      <pubDate>Sat, 27 Sep 2008 22:30:08 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-7866</guid>
    </item>
    <item>
      <title>By Shih Kuo (Intel)</title>
      <description><![CDATA[ sometimes expectation or intuition can lead to a discovery, other times it can trip us instead. 

If you think an os api is providing you with information that is not consistent with the reference code, I can go over the detail of the printout of the reference code and the print out of the information you collected from the api.

If your intuition make you believe any portion of the print out of the reference code is questionable, can you send me the printout in a text file? you can send them to shihjong.kuo@intel.com

Please remember that a &#34;die&#34; inside a package is not a topology level that can be enumerated by the reference code, nor any OS can enumerate the existence of single-die or two-die implementation of multiple cores inside a physical package. This might be an area, intuition might play trick for you.

Another aspect is that each component of the software stack that tries to report topology information can implement some numbering scheme regarding logical processors, so Ihave to be careful when you refer to p0, p1, etc. which two pieces of software you are making comparison...

To expand a little more on your last question:
in the booting up process

1. at reset, APIC ID are assigned at hardware level, at this point control has not been transferred to any software, not even BIOS.
2. after the Bios takes control of the BSP, bios will round up the other logical processors (application processors in BIOS parlance) in the system and prepare some internal data structure with information about APIC ids of the BSP and APs. Obviously Bios can have some numbering system.
3. After BIOS transfer control to the OS along with the data structures defined by ACPI, how the OS choose to identy individual logical processor, it is up to each OS. Linux uses an ordinal numbering system starting from 0, Windows uses an affnity mask. You can associate a numbering system of individual bit of an affinity mask with some numbering system. But between Windows and Linux, this 0-based ordinal numbering schem may or may not be the same on the same hardware installed with both Linux and Windows with dual-boot configuration.

So if you&#39;re asking about #1, I can go over the printout that executed from your machine. If you want to ask #2 or #3, that&#39;s up to the bios and OS. ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-8094</link>
      <pubDate>Fri, 03 Oct 2008 20:41:27 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-8094</guid>
    </item>
    <item>
      <title>By Sam Baskinger</title>
      <description><![CDATA[ 
The file mk_32.sh has the line: gcc -m32 -g -c util_os.c -o util_os.c

I think that it was meant to be: gcc -m32 -g -c util_os.c -o util_os.o

The output file is a .o instead of a .c. :) Regardless, thank you for the code! While I have you attention, any caveats for the snazzy-new i7s? Thanks!


 ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-9254</link>
      <pubDate>Wed, 26 Nov 2008 10:29:43 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-9254</guid>
    </item>
    <item>
      <title>By Alec Fistrovici</title>
      <description><![CDATA[ ! am trying to find information about about buying or perhaps biuldind a laptop type portable pc with a latest intel mobile Quad chip . Does Intel already configure or produce a Xeon quad mobile with a 64 bit program compatability or is there a configuration utility tool for matching the specific mobile quad chip to the proper mobile mother board? I cant find the information on the Intel site relating to this issue.Any advice or info would be appreciated .Thanks           e-mail:bobcat445@rogers.com
                                                       Regards,Alec Fistrovici ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-12465</link>
      <pubDate>Fri, 26 Dec 2008 16:33:22 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-12465</guid>
    </item>
    <item>
      <title>By FvM</title>
      <description><![CDATA[ Hola engo un problema con Mi Laptop pero quiero recuperarlo por que es mi Gusto ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-18372</link>
      <pubDate>Sat, 07 Feb 2009 19:27:08 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-18372</guid>
    </item>
    <item>
      <title>By Shih Kuo (Intel)</title>
      <description><![CDATA[ Sam, thanks for catching the typo. The reference code should work fine for i7s. ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-19855</link>
      <pubDate>Thu, 19 Feb 2009 12:54:50 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-19855</guid>
    </item>
    <item>
      <title>By lio</title>
      <description><![CDATA[ I meet the same problem specified by CQ Tang. 
Our platform consists of dual Woodcrest Xeon 5345 processors. 
From /proc/cpuinfo, #0 #1 #4 and #5 are in package 0. 
And with the reference code, the result is:
#0 and #1  share one L2 cache
#4 and #5  share another L2 cache
But the result from ping-pong test shows that:
Communication between #0 and #4 has the top perfermance.
Communication between #0 and #1 has the same perfermance with Communication between #0 and #5, and the perfermance is much lower than Communication between #0 and #4.
Communication between #0 and #2,#0 and #3,#0 and #6,#0 and #7 are same in performance.
It shows that #0 and #4 share a same L2 cache.

I have repeated the test for many times, and I think maybe the reference code has some bugs.  

P.S. Your work is great! ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-20203</link>
      <pubDate>Mon, 23 Feb 2009 07:05:18 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-20203</guid>
    </item>
    <item>
      <title>By ananthnarayan_s</title>
      <description><![CDATA[ The build script bug reported by Sam doesn't appear to have been fixed. :) ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-20646</link>
      <pubDate>Thu, 05 Mar 2009 20:28:58 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-20646</guid>
    </item>
    <item>
      <title>By Shih Kuo (Intel)</title>
      <description><![CDATA[ I had a few off-line email exchanges to root cause Mr. lio's observations. The correlation of expected performance characteristics relative to the output example of topology enumeration may be of interest to other folks. 

To recap the background, the situation under test was dealing with ping-pong data transimission of a pair of affinitized transmit/receive agents. 

If the affinitization of logical processors of the transimitter/receiver pair are sharing the same L2 cache, one can expect that the latency of such ping-pong data transmission will be lower than if data have to go out on the bus. 

The ping-pong test was run on a Linux system and affinity is controlled using a mask that is equivalent to the CPU_SET API. The hardware is a dual-socket quad core system.

So, how does one go about mapping a pair of ordinal numbers sent to the CPU_SET API and be cerain those ordinal numbesr control two processor coress sharing the same L2?
In this case there are three sets of numbers that are relevant:

1. The composite Affinity mask for the target L2, for a cache level shared by two logical processors, the composite mask will have two non-zero bit. 

The tutorial portion of the code example can print out a small box diagram that shows the L2 mapping to affinity masks, the diagram below depicts the L2 cache level in one of the two quadcore processor:

            +----+----+----+----+
Cache    |  L2        |  L2         |
Size       |  4M       |  4M        |
CmbMsk  |  11        |  22        |
            +----+----+----+----+

2. Since CPU_SET uses an ordinal index to specify individual logical processor, we need a listing of the logical processor affnity mask relative to the ordinal numbers that software can use to iterate individual logical processor. The example code also produces the following listing that connects the three sets of numbers (combined mask of each L2, and affinity masks of each logical processor listed in numerical order of the ordinal numbers)

Affinity mask 00000001 - apic id 0
Affinity mask 00000002 - apic id 2
Affinity mask 00000004 - apic id 4
Affinity mask 00000008 - apic id 6
Affinity mask 00000010 - apic id 1
Affinity mask 00000020 - apic id 3
Affinity mask 00000040 - apic id 5
Affinity mask 00000080 - apic id 7

3. From the Composite mask value of "11H", which corresponds to affinity mask value of 01H (ordinal number 0 in the listing) and 010H (ordinal number 4). The sequence of ordinal number pair that software can use to affinitize the ping/pong transmitter/receiver test to take advantage of L2 is (0, 4), or (1, 5), (2, 6), (3, 7). The first pair matches what was observed by Mr. Lio.

It is important to realize that the numercal order of an ordinal numbered index (for CPU_SET in Linux or SetThreadAffinity ) does not imply a direct mapping relationship to any cache level (L1 Data cache, L1 Instruction cache, L2, etc). 

In a single-socket quad-core system, you may see the following:
             +----+----+----+----+
Cache     |  L2        |  L2         |
Size        |  4M       |  4M        |
CmbMsk   |   3        |   c         |
             +----+----+----+----+

and an ordinal numbered listing of 

Affinity mask 00000001 - apic id 0
Affinity mask 00000002 - apic id 1
Affinity mask 00000004 - apic id 2
Affinity mask 00000008 - apic id 3

One interesting about this is that optimal pairing of affinity control (via affinity mask or equivalent) is highly workload specific.

As, Mr. Lio observed, pairing logical processor (0, 1) in a dual-socket, quad-core topology did not produce the best latency in transmission/receiver test. On a single-socket quadcore system, that pairing would. 

On the other hand, one factor in scheduling heuristic is to minimize cache evictions due to context switches. More than 90% of the wall clock cycles often lads on the system Idle loop, implying it is more common to have several unsubscribed logical processor resources available when a runnable task is added to the queue. 

On a dual-socket, quadcore system shown above, using consecutive sequence of ordinal number to schedule a new task can take advantage of the capacity of L2 without causing evictions on other tasks that were already running.

But applying the same consecutive sequence of ordinal-numbered heuristic to a single-socket quadcore system could result in competition of the L2 capacity by two tasks. So cache evictions caused by starting another task may have some visible performance impact, depending on the size of respective working set. 

  ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-20755</link>
      <pubDate>Mon, 09 Mar 2009 12:48:31 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-20755</guid>
    </item>
    <item>
      <title>By Kevin</title>
      <description><![CDATA[ Couple of minor points:

1 The Unix shell files should have unix line endings

2 when run the following warning was generated

cpu_topo.c: In function ‘DumpCPUIDArray’:
cpu_topo.c:1857: warning: comparison is always false due to limited range of data type

looks like the 'cres' variable should be unsigned perhaps... ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-24547</link>
      <pubDate>Tue, 19 May 2009 02:09:32 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-24547</guid>
    </item>
    <item>
      <title>By Parallel Programming Talk - Counting Cores on the Listener Question Show</title>
      <description><![CDATA[ n/a ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-25457</link>
      <pubDate>Tue, 02 Jun 2009 11:43:53 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-25457</guid>
    </item>
    <item>
      <title>By Kumaravel</title>
      <description><![CDATA[ How to find the Number of Physical Processor Count & Number of Core(s) per Physical Processor on Intel Xeon E5540 Processor?
I have tried using the CPUID, But could not able to find exact bit location. But My code will working fine in Single (Intel Xeon) processor system.

Thanks
Kumaravel ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-31117</link>
      <pubDate>Wed, 16 Sep 2009 04:32:38 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-31117</guid>
    </item>
    <item>
      <title>By Geoffrey Grinton</title>
      <description><![CDATA[ I have been using this code for some time - thanks!
But I am also aware of, and have started using the code in Khang Nguyen's article and the HTMultiCore library.
Now I am trying to reconcile the two sets of data, and need help please.
Here is output on my Lenovo ThinkPad, using the distributed sample programs.

HTMultiCore tells me:
   Hyper-Threading Technology: Not Capable
   System: Multi-core
   Number of available logical processors per physical processor: 1
   Number of available cores per physical processor: 2
   Number of physical processors: 1

cpu_topo tells me:
  Number of logical processors visible to the OS: 2
  Number of logical processors visible to this process: 2 
  Number of processor cores visible to this process: 2
  Number of physical packages visible to this process: 1

And, for reference, the systeminfo command tells me:
  System type:       X86-based PC
  Processor(s):       2 Processor(s) Installed.
                           [01]: x86 Family 6 Model 15 Stepping 10 GenuineIntel ~1995 Mhz
                           [02]: x86 Family 6 Model 15 Stepping 10 GenuineIntel ~1994 Mhz

It is unclear to me whether the terms "physical processor" (HTMultiCore) and "physical package" (cpu_topo) are synonymous or not. If they are meant to be, then it seems to me that I am getting different answers, since in once case I see 1 logical processor per physical processor, and in the other case, 2 logical processors "visible" - which I presume means per physical package, since there is only one of them.

Can you help me understand how to interpret these results please?

Thanks.
Geoffrey
 ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-33016</link>
      <pubDate>Tue, 20 Oct 2009 21:58:00 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-33016</guid>
    </item>
    <item>
      <title>By Shih Kuo (Intel)</title>
      <description><![CDATA[ Kumravel

The number of physical processors is a system-level information, CPUID instruction only reports raw data within its own logical processor domain. If you look at the reference source code, you can find the utility routine GetSysProcessorPackageCount(). There is another utility routine that reports the total number of cores in the system across all the physical processors, you can derive core count per physical processor from those information. 

Geoffrey

My colleage Khang is aware his library code needs to be updated to correct this inconsistency when it tries to report the number of logical processor per core but the text heading was misleading.


As a separate note, Windows 7 and Server 2008 servicepack 2 have added support for Group_AFFINITY with new APIs to support up to 4 groups of affinity masks. I expect to provide an updated reference code that includes support for GROUP_AFFINITY in the near future.
 ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-34515</link>
      <pubDate>Wed, 11 Nov 2009 13:56:10 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-34515</guid>
    </item>
    <item>
      <title>By Tom Kacvinsky</title>
      <description><![CDATA[ I see this error when running cpu_topology64.out:

got error. maxPackageDetetcted= 1 numMappings= 2 maxPackageDetetcted* numMapping 

I tracked thid one in the code and the problem is that cpuid(&info, 1, 0) results in info.EBX having a bogus value.  There is nothing I can do about this in the code as it is the register values that are incorrect.  Any ideas?  The output of cat /proc/cpuinfo is this:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      :                   Intel(R) Xeon(TM) CPU 3.60GHz
stepping        : 3
cpu MHz         : 3600.298
cache size      : 2048 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm pni monitor ds_cpl est tm2 cid cx16 xtpr
bogomips        : 7110.65
clflush size    : 64
cache_alignment : 128
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      :                   Intel(R) Xeon(TM) CPU 3.60GHz
stepping        : 3
cpu MHz         : 3600.298
cache size      : 2048 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm pni monitor ds_cpl est tm2 cid cx16 xtpr
bogomips        : 7192.57
clflush size    : 64
cache_alignment : 128
address sizes   : 36 bits physical, 48 bits virtual
power management:
 ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-36090</link>
      <pubDate>Fri, 04 Dec 2009 07:44:02 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-36090</guid>
    </item>
    <item>
      <title>By Shih Kuo (Intel)</title>
      <description><![CDATA[ Hi Tom,
When you encountered the error with cpu_topology64.out, can you execute it with the parameter 'c' in the command line, immediately. That will print each leaf function data reported by CPUID to stdout. pls send it to me at shihjong.kuo@intel.com.

It is possible that different BIOS setting may be at play or that an obscure mechanism to force CPUID to not report leaf 4 data may have tricked the software stack. Then topology enumeration can not be done correctly untill that system configuration error is corrected. The raw CPUID data produced by running the 'c' option can help diagonose this issue.
  ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-37123</link>
      <pubDate>Mon, 21 Dec 2009 14:41:29 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-37123</guid>
    </item>
    <item>
      <title>By Intel Software Network Blogs &amp;raquo; Updated WinCPUID/LibCPUID code</title>
      <description><![CDATA[ n/a ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-37139</link>
      <pubDate>Mon, 21 Dec 2009 18:04:05 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-37139</guid>
    </item>
    <item>
      <title>By Updated WinCPUID/LibCPUID code</title>
      <description><![CDATA[ n/a ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-37151</link>
      <pubDate>Mon, 21 Dec 2009 20:40:12 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-37151</guid>
    </item>
    <item>
      <title>By Shih Kuo (Intel)</title>
      <description><![CDATA[ A new release of the topology enumeration reference code has been posted. URL link is at the beginning of this page: topo-12212009.tar. 

In previous reference code implementations, the OS-independent wrapper utility routines for thread context management support APIs in both Windows and Linux environment. In Linux environment, the limit of how many logical processors can be managed by the OS is generally set by each Linux distro through kernel configuration at compile time. Hence, our wrapper utility employing a generic affinity mask with width dynamically allocated at runtime can accommodate different size limit imposed by different distro.

In Windows environment and prior to Platform SDK 7.0a, the width of affinity mask (hence the maximum number of logical processors that OS can manage in the system) is limited to 64 in 64-bit mode (and 32 in 32-bit mode). With the release of Platform SDK 7.0a, new APIs and data structures are defined to support systems with greater than 64 logical processors. The latest topology enumeration reference code release added support for these new APIs that are only available in Platform SDK 7.0a. The Windows binary compiled with the new SDK can run on latest Windows 7 and its siblings using the new APIs. Running the same binary under prior versions of windows where PRCOSSOR_GROUP is not supported, it will use the legacy thread management APIs and report topology information like previous releases of our reference code did before.

A readme file is added in the download package. Detailed code changes are listed there.


 ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-37203</link>
      <pubDate>Tue, 22 Dec 2009 09:09:02 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-37203</guid>
    </item>
    <item>
      <title>By alain020sympatico.ca</title>
      <description><![CDATA[ 20/01/2010
Intel® 64 Architecture Processor Topology Enumeration...
Qu`en dire ...
Et bien je vais essayer ce logiciel car figurez vous que je viens d`installer sur mon PC Windows 7 Professionnel de Microsoft Corporation dont je suis partenaire de plus c`est un système 64 bits et il semble que mon ordinateur un Compaq Presario SR5050NX que j`ai amilioré en ajoutant un deuxième disque dur et en créant un volume RAID en j`ai choisie RAID 1 Mirror question de gout j`ai effectivement un attrait pour la plateforme Mirror plutot que le Main downloading je crois que pour le PC c`est plus soft.
J`ai aussi ajouté 3000 Mo de mémoire RAM ( Random Acces Memory ) plus un modem intégré pour le réseau local donc il repère tout les réseaux disponible pour une connexion internet.
Aussi un deuxième lecteur DVD Lightscribe avec accéllérateur 950 Intel et j`en suis très satisfait.
Personnellement je recommande et ce je l`afirme je parle ici d`Infotek Developpement sur touts ses PC n`intègre que des produits Intel.

Mercie

Alain020 ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-38366</link>
      <pubDate>Wed, 20 Jan 2010 04:27:29 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-38366</guid>
    </item>
    <item>
      <title>By EW</title>
      <description><![CDATA[ fyi problems with util_os.c
under linux, Every version of gcc from 4.1 to 4.4 I've tried gives:
util_os.c:106: error: conflicting types for ‘BindContext’  and won't compile. 

pgcc 9 and 10 say: PGC-S-0137-Incompatible prototype declaration for function BindContext (util_os.c: 106)

Intel's icc: gives til_os.c(105): warning #147: declaration is incompatible with "unsigned int BindContext(unsigned int)" (declared at line 271 of "cputopology.h")
   int BindContext(unsigned int cpu)
       ^

/usr/lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
/tmp/iccr63Oto.o: In function `SetChkProcessAffinityConsistency':
util_os.c:(.text+0xad): undefined reference to `glbl_ptr'
util_os.c:(.text+0xbb): undefined reference to `SetGenericAffinityBit'
util_os.c:(.text+0xc2): undefined reference to `glbl_ptr'
util_os.c:(.text+0xd0): undefined reference to `SetGenericAffinityBit'
util_os.c:(.text+0xd9): undefined reference to `glbl_ptr'


Might want to fix that.

 ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-49219</link>
      <pubDate>Thu, 23 Sep 2010 13:09:34 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-49219</guid>
    </item>
    <item>
      <title>By avetec_ed</title>
      <description><![CDATA[ so under linux, aparently you have BindContext declared in cputopology.h and in util_os.c.  this is a problem.

gcc won't compile it. 
error: conflicting types for ‘BindContext’

portland won't compile it
Incompatible prototype declaration for function BindContext 

Intel ICC 11.1 will compile this with errors. but 10 and 9 gag on it as well.

might want to fix this.  interesting program. 
 ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-49220</link>
      <pubDate>Thu, 23 Sep 2010 13:46:38 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-49220</guid>
    </item>
    <item>
      <title>By CPU拓扑结构的调查 | Erlang非业余研究</title>
      <description><![CDATA[ n/a ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-49311</link>
      <pubDate>Fri, 24 Sep 2010 22:32:06 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-49311</guid>
    </item>
    <item>
      <title>By Shih Kuo (Intel)</title>
      <description><![CDATA[ There is a mismatch of the return type of BindContext() between the header file and util_os.c.

Another subtle bug has also been reported by one of my colleaque.

in line 323 of util_os.c, the code is windows specific and uses the new Thread Group AffinityAPIs. The intent is to iterate each processor group and count the populated bits of the affinity mask associated with each group. Therefore Line 323 should have count the bits of the affinity mask of the target group, not the previous group.  

Tallying the bits of the previous group after calling the new SetThreadGroupAffinity() API can lead to erroneous tally if the the executing context of this code starts in a logical processor in processor group ID = higher than 0.
 ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-49432</link>
      <pubDate>Mon, 27 Sep 2010 16:46:43 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-49432</guid>
    </item>
    <item>
      <title>By Frank Illenseer</title>
      <description><![CDATA[ There seems to be a detection deficiency of this tool / method for the following configuration:

CPU: Intel(R) Xeon(R) CPU X7542  @ 2.67GHz (Intel64 Nehalem-EX/Beckton)
Config:  8 physical cpus x 6 cores each x 1 thread (HT is OFF) = 48 logical processors

But the tool detects this system as:

        Software visible enumeration in the system:
Number of logical processors visible to the OS: 48
Number of logical processors visible to this process: 48
Number of processor cores visible to this process: 16
Number of physical packages visible to this process: 2


        Hierarchical counts by levels of processor topology:
 # of cores in package  0 visible to this process: 8 .
         # of logical processors in Core 0 visible to this process: 4 .
         # of logical processors in Core  1 visible to this process: 3 .
         # of logical processors in Core  2 visible to this process: 4 .
         # of logical processors in Core  3 visible to this process: 4 .
         # of logical processors in Core  4 visible to this process: 3 .
         # of logical processors in Core  5 visible to this process: 4 .
 # of cores in package  1 visible to this process: 8 .
         # of logical processors in Core 0 visible to this process: 4 .
         # of logical processors in Core  1 visible to this process: 3 .
         # of logical processors in Core  2 visible to this process: 4 .
         # of logical processors in Core  3 visible to this process: 4 .
         # of logical processors in Core  4 visible to this process: 3 .
         # of logical processors in Core  5 visible to this process: 4 .

So there seems to be some problem...?
The Intel tool "cpuinfo" as shipped with Intel MPI v4 does correct detection:
=====  Processor composition  =====
Processors(CPUs)  : 48
Packages(sockets) : 8
Cores per package : 6
Threads per core  : 1

So I wonder why this code here does not and what is the difference...
I will also send you a personal email with mode details and additional output. ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-49874</link>
      <pubDate>Thu, 07 Oct 2010 02:45:47 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-49874</guid>
    </item>
    <item>
      <title>By farphadet</title>
      <description><![CDATA[ Hi,

This software doesn't work on 2.6.18-164 with this CPU:

Intel(R) Xeon(R) CPU           E5462  @ 2.80GHz    Dual Socket
Intel(R) Xeon(R) CPU           X5570  @ 2.93GHz    Dual Socket
Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz    Dual Socket

I've got this error :

 Encountered error code : c1000000

 ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-52181</link>
      <pubDate>Wed, 24 Nov 2010 07:26:27 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-52181</guid>
    </item>
    <item>
      <title>By Cornelius Nelson (Intel)</title>
      <description><![CDATA[ Up to at least revision 028, Application Note 485 contained a description of the contents of EBX resulting from executing CPUID with input 1. Only the brand ID part is halfway documented in revision 036, and no revision ever gave more than the vague "Valid for Pentium 4 and subsequent processors" for the local APIC physical ID field.

It is really that latter part that I'm after: How can I reliably determine whether a processor that doesn't support CPUID leaf 0xb provides its LAPIC ID in the high eight bits of EBX in leaf 1? ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-52847</link>
      <pubDate>Thu, 02 Dec 2010 14:58:46 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-52847</guid>
    </item>
    <item>
      <title>By Noppadon Sirikhum</title>
      <description><![CDATA[ Thank you for the tools. I compiled and executed it on RHEL 5.4 without any problem. However the result from the tools is inconsistent with data from /proc/cpuinfo. The inconsistency leave me in doubt. I'm not sure from which data should I trust.


cpu_topology64.out reports the OScpu#2 is P#0 C#1, see belows:

Package 0...
[...]
 +----+----+----+----+
Cache | L1D| L1D| L1D| L1D|
Size  | 32K| 32K| 32K| 32K|
OScpu#|   0|   2|   4|   6|
Core  |  c0|  c1|  c2|  c3|
[...]



However, /proc/cpuinfo reports OScpu#2 is P#0 C#2 as opposed to P#0 C#1. Note that OScpu#, P#, and C# from both cpuinfo and cpu_topology64.out are all started from 0. Below are cut-down of cpuinfo in question:

processor       : 2
[...]
model name      : Intel(R) Xeon(R) CPU           X5450  @ 3.00GHz
[...]
physical id     : 0
siblings        : 4
core id         : 2
cpu cores       : 4
[...]



Best regards,
NS ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-55190</link>
      <pubDate>Tue, 18 Jan 2011 00:59:06 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-55190</guid>
    </item>
    <item>
      <title>By Parallel Programming Talk &amp;#8211; Counting Cores on the Listener Question Show &amp;#8211; Intel Software Network Blogs</title>
      <description><![CDATA[ n/a ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-55778</link>
      <pubDate>Mon, 31 Jan 2011 13:07:48 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-55778</guid>
    </item>
    <item>
      <title>By Bernard Tremblay</title>
      <description><![CDATA[ Please would you post a link to the executable cpucount.exe ?

I have no compiler on my computer at work and would like to use cpucount.exe

Regards,

               BT ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-56185</link>
      <pubDate>Fri, 11 Feb 2011 08:33:47 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-56185</guid>
    </item>
    <item>
      <title>By Shih Kuo (Intel)</title>
      <description><![CDATA[ I have been a little bit invisible in attending to reader comment and feedback. I like to thank all for your patience and try to summarize in this batch.

I had several email exchanges with Frank last year, as it was a system with unique capability in HW and SW. Hopefully with help from the vendor rep, work-around may have addressed the important issues. 

@farphadel: the error code 0xc1000000 was logged after the program attempted to verify whether the execution context successfully binded to the requested logical processor, and it failed in your system. I suspect there might be some local system specific issue between either the kernel version and its dependent software library that affect either sched_setaffinity() or schedule_getaffinity() API. If either of these API does not work properly, the program can not proceed. The only advice I have is to consider upgrade to a more modern environment.

@Cornelius: Not sure I follow your comments. The code in the function CPUToplogyParams() shows how to determine the presence of valid leaf 0xB. When you run it on a P4, maxCPUID will be less than 11. No need to worry about brand index.

@Noppadon: The part that can be confusing is the numbering conventions, I used one convention as I tried not to be tied to how Windows or Linux handle data objects within their own domain. Think of the numbering system of house number, street numbers or zip codes. The address numbering system that mail carrier uses is different from city planning and taxation, or by lat/lon. 

Each logical processor has unique initial APIC ID (leaving aside Frank's unique situation). Which logical processor (in terms of initial APIC ID) will be chosen by the macro __CPU_SET with the number '0'? Neither the HW nor OS pose restriction on which shall be the luck one. 

But whichever got assigned and established as OS boots up, you can find that out. If you start with the OS's numbering system, you use __CPU_SET() and sched_set_affinity(), and then executing CPUID with leaf 1 can tell you what is the initial APIC ID of OScpu#0 or any other for this OS in your booted session. 

In my code, I use a numbering convention independent of OS. But under the hood, I translate my OS-independent numbering system to the actual OS-specific interface to conduct any thread-binding chores. Hope this help.

@Bernard: Executables are platform specific and sometime sensitive to some local issues (like my conjecture in replying to Farphadel, but if you are not running a modern OS, I may not be able to help). If you send me an email (to shihjong.kuo@intel.com) and let me know which Windows or Linux system you need, I can give it a try.
 ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-56190</link>
      <pubDate>Fri, 11 Feb 2011 12:35:41 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-56190</guid>
    </item>
    <item>
      <title>By Noppadon Sirikhum</title>
      <description><![CDATA[ Shih Kuo,

Thank you for your answer. However still I am not so clear about the situation. Ultimately, I want to get a map between two addressing conventions, physical and logical. The issue is the map from cpu_topology64.out does not agree with /proc/cpuinfo:


/proc/cpuinfo says:
processor 0 - core id 0
processor 2 - core id 2
processor 4 - core id 1

cpu_topology64.out:
OScpu#0 - Core c0
OScpu#2 - Core c1
OScpu#4 - Core c2


If I want to bind processes/threads to two closet cores, should I bind to logical#0 with logical#2 or logical#4?


Thank you in advance,
N ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-57875</link>
      <pubDate>Thu, 24 Mar 2011 21:15:53 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-57875</guid>
    </item>
    <item>
      <title>By Shih Kuo (Intel)</title>
      <description><![CDATA[ Hi Nappodon

Hi

With respect to your ultimate goal, the hierarchical levels that have performance implications are package/core/SMT. These three levels can be enumerated architectually. 

Within the same physical package (socket), does the notion of different proximity between core 0, 1, 2, 3 meaningful to worth extra effort?

For multicores made of monolithic dies like Nehalem/Wesmere/Sandy Bridge generations. theere is no meaniful difference. Even with ring inter-connect between cores, I don't think that's a good reason to consider traffic on the ring worthwhile to treat the cores asymmetrically.
 ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-59200</link>
      <pubDate>Thu, 28 Apr 2011 14:34:48 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-59200</guid>
    </item>
    <item>
      <title>By aklimovsky</title>
      <description><![CDATA[ First, problem with return type of BindContext is still not resolved in current sources.
Second, cputopology.h has many function declarations which are not defined anywhere.
For example,
unsigned  GetCoreCount(unsigned long package_ordinal)
seems to be
unsigned  GetEnumeratedCoreCount(unsigned  package_ordinal)

Function
unsigned  GetProcessorCoreCount()
seems to be
unsigned  GetSysProcessorCoreCount() ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-59374</link>
      <pubDate>Wed, 04 May 2011 05:42:42 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-59374</guid>
    </item>
    <item>
      <title>By Hyper-V Concepts &amp;#8211; vCPU &amp;laquo; Hyper-V blog by Puneet Vig</title>
      <description><![CDATA[ n/a ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-59978</link>
      <pubDate>Sat, 21 May 2011 11:18:35 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-59978</guid>
    </item>
    <item>
      <title>By amolv</title>
      <description><![CDATA[ Hi,

I am using the code from 09272010.
When I run it on my Windows2K3-32 bit box.
This is the error I get:

got error. maxPackageDetetcted= 1 numMappings= 4 maxPackageDetetcted* numMapping
s + 0 = 4 and ckDim= 4 at ....cpu-topologycpu_topo.c 1271


C:cpucount>cpucount.exe C

        Raw Data from Selected CPUID leaves :
func: 0, subfunc 0 EAX:b EBX:756e6547 ECX:6c65746e EDX:49656e69
func: 1, subfunc 0 EAX:206c2 EBX:2010800 ECX:2982203 EDX:febbbff
func: 2, subfunc 0 EAX:55035a01 EBX:f0b2ff ECX:0 EDX:ca0000
func: 4, subfunc 0 EAX:121 EBX:1c0003f ECX:3f EDX:0
func: 4, subfunc 1 EAX:122 EBX:c0003f ECX:7f EDX:0
func: 4, subfunc 2 EAX:143 EBX:1c0003f ECX:1ff EDX:0
func: 4, subfunc 3 EAX:163 EBX:3c0003f ECX:2fff EDX:2
func: 4, subfunc 4 EAX:0 EBX:0 ECX:0 EDX:0
func: 11, subfunc 0 EAX:0 EBX:1 ECX:100 EDX:1
func: 11, subfunc 1 EAX:0 EBX:1 ECX:201 EDX:1
func: 11, subfunc 2 EAX:0 EBX:0 ECX:2 EDX:1
Max Leaf b, 80000008

This is a VM on ESX.
I am studying the code to find whats going wrong, but thought of checking here too in case you have any quick tips.
 ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-62060</link>
      <pubDate>Tue, 19 Jul 2011 02:46:25 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-62060</guid>
    </item>
    <item>
      <title>By Shih Kuo (Intel)</title>
      <description><![CDATA[ Hi Amol

From what you described,  your usage is running win2k3-32 as a guest VM, this is the crux of the problem on usage not a functional issue.

The reference code is designed for usage under native OS for ring 3 code that can interact to HW natively via CPUID. Under a VM, those basic necessities are not always true. So the reference code can not guarantee correctness.

I believe ESX is a bare-metal hypervisor, which means CPUID data received inside a VM were formulated by the hypervisor not from the HW.

You may want to ask what can you do about querying topology inside a VM? I don't really have a good answer. 

The reference code is designed to address native hw topology, the problem you're facing is virtual topology presented to the VM by the hypervisor. I suppose VM vendors may be able to devise some API to allow discovery of such information if they have sufficient customer interest. But I don't know if they offer anything specific or not at all.
 ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-62072</link>
      <pubDate>Tue, 19 Jul 2011 09:26:45 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-62072</guid>
    </item>
    <item>
      <title>By CPU拓扑结构的调查</title>
      <description><![CDATA[ n/a ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-63630</link>
      <pubDate>Tue, 30 Aug 2011 09:11:48 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-63630</guid>
    </item>
    <item>
      <title>By Kevin Closson</title>
      <description><![CDATA[ This valuable tool *still* does not work compile.
# uname -a
Linux mdw 2.6.18-194.26.1.el5 #1 SMP Fri Oct 29 14:21:16 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
# sh ./mk*64*sh
util_os.c:106: error: conflicting types for ?BindContext?
cputopology.h:271: error: previous declaration of ?BindContext? was here
gcc: util_os.o: No such file or directory


can you folks *please* fix this? ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-64446</link>
      <pubDate>Sat, 17 Sep 2011 11:47:21 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-64446</guid>
    </item>
    <item>
      <title>By Linux Thinks It&amp;#8217;s a CPU, But What Is It Really &amp;#8211; Part I. Mapping Xeon 5500 (Nehalem) Processor Threads to Linux OS CPUs. &amp;laquo; Kevin Closson&amp;#039;s Blog: Platforms, Databases and Storage</title>
      <description><![CDATA[ n/a ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-64447</link>
      <pubDate>Sat, 17 Sep 2011 11:57:43 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-64447</guid>
    </item>
    <item>
      <title>By Håkon</title>
      <description><![CDATA[ Would it be possible to extend this program to enumerate the QPI links and reveal the QPI topology of the system? That is, how many QPI links, width and speed thereof, and how are they connected?

Thanks, Håkon ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-65648</link>
      <pubDate>Wed, 19 Oct 2011 00:52:31 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-65648</guid>
    </item>
    <item>
      <title>By FSB downclock mod on the intel GL960 and GL40 --- useful info for PLL Modders - Page 6</title>
      <description><![CDATA[ n/a ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-66844</link>
      <pubDate>Fri, 18 Nov 2011 01:29:24 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-66844</guid>
    </item>
    <item>
      <title>By System.h &amp;#8211; 1324410639305 - Source Code</title>
      <description><![CDATA[ n/a ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-68410</link>
      <pubDate>Tue, 20 Dec 2011 11:51:02 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-68410</guid>
    </item>
    <item>
      <title>By Pramod</title>
      <description><![CDATA[ Dear Sir,
Whic processor is more updated -Processor x86 Family 6 Model 23 Stepping 10 GenuineIntel ~3000 Mhz
Or Intel P1V. Pls suggest. ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-70125</link>
      <pubDate>Thu, 09 Feb 2012 00:42:34 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-70125</guid>
    </item>
    <item>
      <title>By Abdulhakeem</title>
      <description><![CDATA[ Thanks a lot  ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-70134</link>
      <pubDate>Thu, 09 Feb 2012 05:58:57 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-70134</guid>
    </item>
    <item>
      <title>By Abdulhakeem</title>
      <description><![CDATA[ Thanks a lot  ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-70135</link>
      <pubDate>Thu, 09 Feb 2012 06:00:24 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-70135</guid>
    </item>
    <item>
      <title>By Shih Kuo (Intel)</title>
      <description><![CDATA[ @Kevin, pls bear in mind the code is released in the spirit of facilitating folks who are willing to experiment in the DIY mode to understand the lowest-level interaction between HW and OS while in user mode. Some cosmetic or minor issues that are present should be within the typical knowhow for Linux programmers dealing with ideosynchrocies of different distributions, tool chain evolution, kernel version, etc. I'm sorry your expectation may be different, as your experience seems to be related to the local environment/older versions.

@Hakon, I'm not very knowledgeable with the QPI stuff. I think the information you wanted to query from QPI is probably typical PCI config space communication programming between a host and the targets. Those communications are happening at a entirely difference device address space (not APIC ID address space as CPU communicates to each other), and using commands specific to the device domain (not x86 ISA as CPU do).

@Pramod, Family 6 Model 23 first launched in late 2007, so yours is more likely a 2008 product or later. The last generation of P4 came to market in 2006. ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-73410</link>
      <pubDate>Fri, 27 Apr 2012 15:41:35 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-73410</guid>
    </item>
    <item>
      <title>By Pat Heavey</title>
      <description><![CDATA[ The compile error can be corrected by changing the return type of BindContext() to 'int' in cputopology.h.

I'm not sure why Mr Kuo can't be bothered to fix this - surely it would be simpler than dealing with the questions that are sure to keep coming up.  Maybe it's a shibboleth, to make sure no non-programmers can run the utility ?

I also ran into the '         Encountered error code : c1000000' issue on an RHEL 6.2 system.
The utility requires an unrestricted CPU affinity set, but we had used Red Hat's "tuna" utility to isolate certain CPUs from user processes, hence the error code.  Make sure cpu-topology is allowed to run on any and all cpus on your system. ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-73770</link>
      <pubDate>Mon, 07 May 2012 09:36:13 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/#comment-73770</guid>
    </item>
  </channel></rss>
