/proc/cpuinfo and hyperthreading

Khannie

Ok...this question may be based on ignorance, so here's my understanding first off:

Hyperthreaded cores are not "real" cores. The architectures allows you to use essentially unsed parts of a physical core to reduce the time through the instruction pipeline.

Now, here's the thing: I have a box with 2 x quad cores in it. It says it has 16 processors in /proc/cpuinfo. I can identify physical id (i.e. socket), core id, yada yada but what I want to know is which of the listed CPU's is a "real" core, and which is a "hyperthreaded" core. I will be using taskset to set the affinity of a particular app and I want to make sure I'm using physical / actual cores without disabling hyperthreading in the bios.

Any help appreciated.

ressem

It's not really as you describe.
When hyperthreading is enabled, it is not the case that there is still one real core and one simulated core.
With hyperthreading, there are two logical cores. Both are equivalent and there isn't a flag to distinguish one from another.

So if you can't, for some tested reason, trust the kernel then it doesn't matter which of the 2 logical cores provided you don't assign the task on both logical cores.

The two logical cores will share the same physical ID and the same Core ID.

But the modern kernel will try by default to create the processes so as to share as little as possible, unless it thinks that there are efficiency gains to be made by sharing.

Khannie

ressem wrote: »

It's not really as you describe.
When hyperthreading is enabled, it is not the case that there is still one real core and one simulated core.
With hyperthreading, there are two logical cores. Both are equivalent and there isn't a flag to distinguish one from another.

Ok, thanks for that. Though it's a pain in the balls. They're not *really* equivalent cores...I mean performance for the first 50% of cpu usage is significantly higher than the second 50%. In fact, even approaching 100% cpu usage on a hyperthreaded system seems to be very difficult indeed.

ressem wrote: »

The two logical cores will share the same physical ID and the same Core ID.

Confirmed:

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 26
model name	: Intel(R) Xeon(R) CPU           X5570  @ 2.93GHz
stepping	: 5
cpu MHz		: 2933.533
cache size	: 8192 KB
physical id	: 1
siblings	: 8
core id		: 0
cpu cores	: 4
apicid		: 16
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
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 nx rdtscp lm constant_tsc ida nonstop_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr sse4_1 sse4_2 popcnt lahf_lm
bogomips	: 5867.06
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management: [8]


processor	: 8
vendor_id	: GenuineIntel
cpu family	: 6
model		: 26
model name	: Intel(R) Xeon(R) CPU           X5570  @ 2.93GHz
stepping	: 5
cpu MHz		: 2933.533
cache size	: 8192 KB
physical id	: 1
siblings	: 8
core id		: 0
cpu cores	: 4
apicid		: 17
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
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 nx rdtscp lm constant_tsc ida nonstop_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr sse4_1 sse4_2 popcnt lahf_lm
bogomips	: 5867.17
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management: [8]

ressem wrote: »

But the modern kernel will try by default to create the processes so as to share as little as possible, unless it thinks that there are efficiency gains to be made by sharing.

It's an old kernel. 2.6.18-194.el5. Do you mean though that if I apply an affinity with 4 different physical cores and there's little else happening on the system I am essentially assured a full physical core?

Also, let's say I set affinity to all cores on processor with physical id 0, that's essentially the same as comparing it to a single socket, hyperthreaded machine, right?

ressem

They're not *really* equivalent cores...I mean performance for the first 50% of cpu usage is significantly higher than the second 50%.

Yep, because it's two logical cores sharing one physical core.

I guess you've been through comp sys or equivalent so you're aware that the processor has an instruction pipeline to allow it to carry out instructions like memory fetch, store, decode on the same clock cycle as another instruction. I think your Nehalem type have a 14 stage pipeline.

What your logical cores are meant to achieve is filling the empty slots on this pipeline that occur while a single thread is monopolising a physical core. This achieves a few percent better efficiency, but will never double performance outside a lab experiment.

But choosing processor 0 over 8 in your list below should make no difference.
And because of this simple CPU % free/used/maximum is hard to measure on a hyperthreaded setup.

It's an old kernel. 2.6.18-194.el5. Do you mean though that if I apply an affinity with 4 different physical cores and there's little else happening on the system I am essentially assured a full physical core?

Yes. On your machine you'll have 8 unique combinations of (PhysId [0-1] AND CoreId [0-3]). If your scheduler assigns one task to each of these, they'll be the only thing using that core's pipeline, until the OS runs something else.

Also, let's say I set affinity to all cores on processor with physical id 0, that's essentially the same as comparing it to a single socket, hyperthreaded machine, right?

Not sure. Lots of other potential bottlenecks in a system. If the other processor is doing nothing then I'd hazard a yes.

Khannie

Nice one, thanks. Yeah, I knew that about the pipelining alright and that that was how hyperthreading sucked that last few percentage points out of the processor. It's a fairly clever idea really. In the software I was looking at we were seeing around 20-30% extra "processing units" with hyperthreading on. I was fairly surprised. In the old P4 architecture I never saw anything even approaching that.