6

I'm having an issue with my CPUID-based code on newer i7-based machines. It is detecting the CPU as having a single core with 8 HT units instead of 4 cores each with 2 HT units.

I must be misinterpreting the results of the CPUID information coming back from the CPU, but I can't see how.

Basically, I iterate through each processor visible to Windows, set thread affinity to that thread and then make a sequence of CPUID calls.

args = new CPUID_Args();
args.eax = 1;
executeHandler(ref args);
if (0 != (args.edx & (0x1 << 28)))
{
  //If the 28th bit in EDX is flagged, this processor supports multiple logical processors per physical package
  // in this case bits 23:16 of EBX should give the count.
//** EBX here is 0x2100800
  logicalProcessorCount = (args.ebx & 0x00FF0000) >> 16;
//** this tells me there are 16 logical processors (wrong)
}
else
{ logicalProcessorCount = 1; }
apic = unchecked((byte)((0xFF000000 & args.ebx) >> 24));

if (maximumSupportedCPUID >= 4)
{
  args = new CPUID_Args();
  args.eax = 4;
  executeHandler(ref args);
//EAX now contains 0x1C004121
  coreCount = 1 + ((args.eax & 0xFC000000) >> 26);
//This calculates coreCount as 8
}
else
{ coreCount = 1; }

This sequence repeats for the remainder of the CPUs in the system.

Has anyone faced this before?

phuclv
  • 37,963
  • 15
  • 156
  • 475
StarPacker
  • 529
  • 4
  • 4
  • Hey StarPacker, although I'm afraid I will not be able to help you with this specific issue I have a related question: http://stackoverflow.com/questions/1666093/cpuid-implementations-in-c I was wondering if you could set me on the correct path with some example code or something... I would really like to have X86/X64 support for CPUID in my app to get back processor info/features in crash reports for an app I am developing and that will be used by fellow researchers (ho will run my code on machines I will not be able to access directly). Cheers, Kris – Kris Nov 03 '09 at 09:41

1 Answers1

5

Interesting question - unfortunately I don't have an i7 to play with, so I can only guess here.

It may be useful to have a look at this article - while in principle your approach seems correct, they state a few caveats. Maybe have a read and see whether at any stage any of your assumptions may be wrong. They essentially use CPUID.1.EBX[23:16] (max # log processors in a physical package), CPUID.4.EAX[31:26]+1 (max # of cores in a physical package) and CPUID.4.EAX[25:14]+1 (max # of log processors in a physical package sharing the target level cache) to infer the processor topology - which is along the lines of what you're doing.

Secondly, as an alternative, on a CPU which supports the CPUID function EAX = 0Bh (see Intel's docs here), you may use this function instead to get the specs you want. Maybe comparing the results of the two approaches may be illuminating?

--Edit-- This is a very useful article which covers both of the approaches above. Essentially, I gather that on an i7, CPUID.0B is the preferred variant.

PhiS
  • 4,540
  • 25
  • 35
  • Thank you for this answer. Pity it wasn't accepted as it answers this question perfectly. – ttvd Jul 12 '11 at 23:29
  • I'm having this same problem on an i5-560m, where CPUID.1.EBX[23:16] is reporting 16 logical processors instead of 4. I have no idea why it's returning an incorrect result. While the first article PhiS linked to may have contained the answer, it's been taken down. The other links don't really provide an answer. Even if an alternate method works, there still doesn't seem to be any rhyme or reason to why the first one doesn't. :-/ – Mike S Sep 27 '11 at 15:56
  • Ah - the second article does in fact say why CPUID.1.EBX[23:16] doesn't work: Contrary to what AP-485 implies, it doesn't actually return the real number of logical processors: "CPUID.1:EBX[23:16] represents the maximum number of addressable IDs (initial APIC ID) that can be assigned to logical processors in a physical package. The value may not be the same as the number of logical processors that are present in the hardware of a physical package." Argh, the simplest stuff is buried so deeply...as if application developers care more about the theoretical max than the real number of threads. – Mike S Sep 27 '11 at 17:13