Skip to contentSkip to conversation

detecting hyperthreading in linux 2.4.19

DISCUSSION Jason Lunz 7 participants 11 messages Jan 9, 2003 – Jan 10, 2003

lore
Share & tools
lore

Jason Lunz

author
#0 lore raw

Is there a way for a userspace program running on linux 2.4.19 to tell the difference between a single hyperthreaded xeon P4 with HT enabled and a dual hyperthreaded xeon P4 with HT disabled? The /proc/cpuinfos for the two cases are indistinguishable.

Jason

#1 lore raw
Quoted 8 lines · Jason Lunz

Is there a way for a userspace program running on linux 2.4.19 to tell the difference between a single hyperthreaded xeon P4 with HT enabled and a dual hyperthreaded xeon P4 with HT disabled? The /proc/cpuinfos for the two cases are indistinguishable.

Jason

-

In the kernel that's no problem:

A) If the BIOS writers followed Intel's guidelines, just look at the physical APIC IDs. HT siblings have odd IDs, the real ones have even.

B) Check the siblings table built up at boot time and used by the scheduler.

I don't know of any way to do this in userland. The whole point is that the sibling processors are supposed to look like real ones.

You _could_ try running two processes simultaneously in tight spin loops for 100 million cycles and comparing the amount of real time consumed. That would be rather unreliable and kludgey though.

Signature · 3 lines
James Cleverdon
IBM xSeries Linux Solutions
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot com
#2 lore raw
Quoted 11 lines
Quoted 4 lines

Is there a way for a userspace program running on linux 2.4.19 to tell the difference between a single hyperthreaded xeon P4 with HT enabled and a dual hyperthreaded xeon P4 with HT disabled? The /proc/cpuinfos for the two cases are indistinguishable.

I don't know of any way to do this in userland. The whole point is that the sibling processors are supposed to look like real ones.

You _could_ try running two processes simultaneously in tight spin loops for 100 million cycles and comparing the amount of real time consumed. That would be rather unreliable and kludgey though.

If /proc/interrupts shows a processor is handling interrupts then it is definitely a 'real' one. If it isn't handling interrupts, it may or may not be a 'real' one. That's another unreliable and kludgey way to tell the difference :-).

John.

#3 lore raw
Quoted 12 lines · John Bradford
Quoted 11 lines
Quoted 4 lines

Is there a way for a userspace program running on linux 2.4.19 to tell the difference between a single hyperthreaded xeon P4 with HT enabled and a dual hyperthreaded xeon P4 with HT disabled? The /proc/cpuinfos for the two cases are indistinguishable.

I don't know of any way to do this in userland. The whole point is that the sibling processors are supposed to look like real ones.

You _could_ try running two processes simultaneously in tight spin loops for 100 million cycles and comparing the amount of real time consumed. That would be rather unreliable and kludgey though.

Quoted 7 lines

If /proc/interrupts shows a processor is handling interrupts then it is definitely a 'real' one. If it isn't handling interrupts, it may or may not be a 'real' one. That's another unreliable and kludgey way to tell the difference :-).

John.
-

Not quite. The "logical" or "sibling" processor has its own local APIC. This is necessary to send it the Startup IPI and soft IPIs while the system is running.

However, it is a full function APIC and can receive I/O interrupts. I have seen this happen many times.

Signature · 3 lines
James Cleverdon
IBM xSeries Linux Solutions
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot com
#4 lore raw
In reply to John Bradford
Quoted 4 lines · John Bradford

If /proc/interrupts shows a processor is handling interrupts then it is definitely a 'real' one. If it isn't handling interrupts, it may or may not be a 'real' one. That's another unreliable and kludgey way to tell the difference :-).

What about something like lmsensors? Wouldn't the motherboard normally report different temperatures for each cpu, since each has its own temp diode?

(this originally was supposed to be a in-jest idea to run two threads and see if one cpu or two cpu's heat up, but then i realized you might as well just count the temperature diodes :D)

Mike

author
#5 lore raw
In reply to James Cleverdon
Quoted 2 lines · [email protected] said:

I don't know of any way to do this in userland. The whole point is that the sibling processors are supposed to look like real ones.

That's unfortunately not always true. I'm writing a program that will run on a system that will be doing high-load routing. Testing has shown that we get better performance when binding each NIC's interrupts to a separate physical processor using /proc/irq/*/smp_affinity (especially when all the interrupts would hit the first CPU, another problem i've yet to address). That only works for real processors, though, not HT siblings.

I'm writing a program to run on machines of unknown (by me) configuration, that will spread out the NIC interrupts appropriately. So userspace needs to know the difference, at least until interrupts can be automatically distributed by the kernel in a satisfactory way.

Jason

#6 lore raw
Quoted 5 lines · Jason Lunz
Quoted 2 lines · [email protected] said:

I don't know of any way to do this in userland. The whole point is that the sibling processors are supposed to look like real ones.

Quoted 7 lines

That's unfortunately not always true. I'm writing a program that will run on a system that will be doing high-load routing. Testing has shown that we get better performance when binding each NIC's interrupts to a separate physical processor using /proc/irq/*/smp_affinity (especially when all the interrupts would hit the first CPU, another problem i've yet to address). That only works for real processors, though, not HT siblings.

Strange, I'm doing the very same thing (not with NICs though) using the local_irq_desc
at the driver level or via /proc/irq/*/smp_affinity method and both work fine. 2.4.18 and 2.4.20 both work here but haven't actually used 2.4.19.

Quoted 5 lines

I'm writing a program to run on machines of unknown (by me) configuration, that will spread out the NIC interrupts appropriately. So userspace needs to know the difference, at least until interrupts can be automatically distributed by the kernel in a satisfactory way.

My userland app doesn't know the difference and works fine whether HT or not. At least according to /proc/interrupts, xosview, and the actual performance of my app.

Mark

#7 lore raw
In reply to James Cleverdon
Quoted 12 lines · James Cleverdon
Quoted 8 lines · Jason Lunz

Is there a way for a userspace program running on linux 2.4.19 to tell the difference between a single hyperthreaded xeon P4 with HT enabled and a dual hyperthreaded xeon P4 with HT disabled? The /proc/cpuinfos for the two cases are indistinguishable.

Jason

-

In the kernel that's no problem:

Quoted 7 lines

A) If the BIOS writers followed Intel's guidelines, just look at the physical APIC IDs. HT siblings have odd IDs, the real ones have even.

B) Check the siblings table built up at boot time and used by the scheduler.

I don't know of any way to do this in userland. The whole point is that the sibling processors are supposed to look like real ones.

If the kernel has sched_setaffinity() or some other way of binding a process to a given CPU (as numbered by the kernel, which may or may not be related to any physical CPU numbers), then this will do it: execute CPUID on each CPU and check the initial APIC ID field. If you find one that's non-zero, then HT is enabled.

My performance monitoring counters driver uses this approach in kernel-space using smp_call_function(). I don't use the siblings tables because they suck :-) [I don't think they distinguish between logical CPUs #0 and #1, and they aren't exported to modules. The CPUID check is simple and portable across kernel versions.]

#8 lore raw
Quoted 5 lines · Mikael Pettersson

If the kernel has sched_setaffinity() or some other way of binding a process to a given CPU (as numbered by the kernel, which may or may not be related to any physical CPU numbers), then this will do it: execute CPUID on each CPU and check the initial APIC ID field. If you find one that's non-zero, then HT is enabled.

That's a horrible way of reimplementing /dev/cpu/x/cpuid 8-)

Dave

Signature · 2 lines
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs
#9 lore raw
Quoted 9 lines · Dave Jones
Quoted 5 lines · Mikael Pettersson

If the kernel has sched_setaffinity() or some other way of binding a process to a given CPU (as numbered by the kernel, which may or may not be related to any physical CPU numbers), then this will do it: execute CPUID on each CPU and check the initial APIC ID field. If you find one that's non-zero, then HT is enabled.

That's a horrible way of reimplementing /dev/cpu/x/cpuid 8-)

True. I forgot about that interface since I personally never configure or use it.

So this answers the original question. Just access /dev/cpu/$CPU/cpuid for all (accessible) values of $CPU.

#10 lore raw
In reply to Jason Lunz
Quoted 4 lines · Jason Lunz

Is there a way for a userspace program running on linux 2.4.19 to tell the difference between a single hyperthreaded xeon P4 with HT enabled and a dual hyperthreaded xeon P4 with HT disabled? The /proc/cpuinfos for the two cases are indistinguishable.

Check out x86info[1]. It should do the right thing in both cases. It counts siblings, and also checks the BIOS MP table.

Dave

[1] http://www.codemonkey.org.uk/x86info/

Signature · 2 lines
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs