Output of /proc/cpuinfo, 2 entries for each core?

Question

Please help me understand the output of /proc/cpuinfo. My new server has dual quad cores. /proc/cpuinfo has two entries for each core (a total of 16 entries):

processor       : 9
vendor_id       : GenuineIntel
cpu family      : 6
model           : 26
model name      : Intel(R) Xeon(R) CPU           X5570  @ 2.9
stepping        : 5
cpu MHz         : 1596.000
cache size      : 8192 KB
physical id     : 0
siblings        : 8
core id         : 0
cpu cores       : 4
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep                                                       pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe sys                                                       onstant_tsc arch_perfmon pebs bts rep_good xtopology tsc_reli                                                       i dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca                                                        lm ida tpr_shadow vnmi flexpriority ept vpid
bogomips        : 5851.05
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 26
model name      : Intel(R) Xeon(R) CPU           X5570  @ 2.9
stepping        : 5
cpu MHz         : 1596.000
cache size      : 8192 KB
physical id     : 0
siblings        : 8
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep                                                       pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe sys                                                       onstant_tsc arch_perfmon pebs bts rep_good xtopology tsc_reli                                                       i dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca                                                        lm ida tpr_shadow vnmi flexpriority ept vpid
bogomips        : 5851.05
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

Why is each core listed twice? Why does the second listing have cpu MHz: 1596.000?

EDITS

After reading the response below, a new question, why would all the Physical id: 0's (which I'm guessing is a chip) be reporting cpu MHz : 1596.000 instead of 2926 like Physical id: 1?

MORE EDITS

Looking through my kernel config, I have CPU Frequency scaling enabled. Is that the culprit? Is it a bad idea to disable it, or in real life would it not make a difference?

Thanks.

Answer 1

There's two entries for each core, because Nehalem (Xeon 55## series) supports two hardware threads per core, which to Linux appears as two processors. The CPU frequency varies because each core can be independently clocked; going by the physical id value the two you've posted appear to be different cores.

Edit: Yes, frequency scaling is why the chips have different speeds. Linux's frequency scaling is pretty good these days days, so there's no harm in leaving it enabled, and it'll save you power (both directly and from reduced cooling costs).

Answer 2

RE: Unexpected CPU Speed

You don't need to worry about this, it's automatic, a power/heat saving feature. When your computer needs full CPU power, it will automatically ramp up the processors to full speed, then ramp them back down when it's done.

You can test this to verify it for yourself. Set up a simple number crunching app without any kind of throttling, and set the processor affinity to one of the lower frequency processors. You should see the frequency jump up to max to accommodate the extra computation.

Answer 3

why would all the Physical id: 0's (which I'm guessing is a chip) be reporting cpu MHz : 1596.000 instead of 2926 like Physical id: 1?

Probably SpeedStep.