Runtime processor detection

[randy_howard]

I would really like to be able to determine the number of physical CPUs in a system. HT processors seem to cause the normal methods to all return double the actual count, but I haven't found anyway to determine via software (apart from poking around in vendor-specific CMOS data for a "Hyperthreading Enable" flag to know for sure if it's a 4-way SMP box, or a dual Xeon/HT.

This does actually matter, despite all the wonderful Intel marketing, for certain types of applications. In such cases, running thread counts based on the number of physical rather than "virtual" processors results in better performance.

I'm guessing there is some cpuid style trick to determine not only if the processor supports HT, but if it is actually running in that mode at the time?

As an aside, I'm also curious if there is a definitive answer to this unrelated question...

Do uses of rdtsc return meaningful results (relative to previous invocations) if the processor the code executes on varies from the first to the later call? Example...

bigtimer1 = my_rdtsc();
exec_something_that_may_bounc_between_cpus();
bigtimer2 = my_rdtsc();

Is this value "synchronized" between CPUs, or is that wishful thinking? Does the answer depend upon HT vs. physical? Chipsets, BIOS developers, etc.?

[randy_howard]

Please disregard the part of the message about determining if HT was present (and enabled) or not, as I found it here:

I am still curious about the rdtsc question though.

Message Edited by intel.software.network.support on 12-09-2005 10:43 AM

[davids]

Linux synchronizes the TSC across CPUs. Other OSes might not.

DS

[jseigh2]

> Linux synchronizes the TSC across CPUs. Other OSes
> might not.

Linux determines the corresponding TSC values and stepping rates at various points in time but they're
not synchronized since the TSC cannot be set.

Unless your thread is bound to a particular processor, there is no way to determine what processor you read
the TSC from. So any calculations using TSC data
would be useless.

You could set up the OS to support high precision
virtual timers or virtual TSC's (it's fairly trivial)
but it's not currently there in any OS (except maybe
IBM mainframes).

Joe Seigh

[randy_howard]

> Linux determines the corresponding TSC values and
> stepping rates at various points in time but they're
> not synchronized since the TSC cannot be set.
>
> Unless your thread is bound to a particular
> processor, there is no way to determine what
> processor you read
> the TSC from. So any calculations using TSC data
> would be useless.

That's pretty unfortunate. So much for that plan. :-)