detecting hyperthreading in linux 2.4.19
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
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/cpuinfosfor 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 comQuoted 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/cpuinfosfor 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.
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/cpuinfosfor 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/interruptsshows 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 comQuoted 4 lines · John Bradford
If
/proc/interruptsshows 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
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
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
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/cpuinfosfor 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.]
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
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/cpuid8-)
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.
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/cpuinfosfor 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