Core ids from cpuinfo are not in strict succession
isopov opened this issue · comments
I have two cores, In cpuinfo first have core id 0, and second have core id 2. Thats why the following assertion fails:
assert cpuDetails.size() == sockets * cores * threads; //cores here has value 3 instead of 2
How about using string "cpu cores : 2" to know number of cores?
Complete /proc/cpuinfo:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 37
model name : Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz
stepping : 2
cpu MHz : 1200.000
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
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 pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm arat tpr_shadow vnmi flexpriority ept vpid
bogomips : 5866.15
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 37
model name : Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz
stepping : 2
cpu MHz : 1200.000
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 2
cpu cores : 2
apicid : 4
initial apicid : 4
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
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 pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm arat tpr_shadow vnmi flexpriority ept vpid
bogomips : 5866.64
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 37
model name : Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz
stepping : 2
cpu MHz : 1200.000
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 1
initial apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
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 pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm arat tpr_shadow vnmi flexpriority ept vpid
bogomips : 5866.62
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 37
model name : Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz
stepping : 2
cpu MHz : 1200.000
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 2
cpu cores : 2
apicid : 5
initial apicid : 5
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
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 pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm arat tpr_shadow vnmi flexpriority ept vpid
bogomips : 5866.65
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
Very interesting. I was of the view that an i3 was a cut down i5. (turning of the core which failed) so its possible this is not the same for all i3 processors (any two of 0,1,2,3 might be possible)
Can you try something for me to test the affinity rules?
for i in 0 1 2 3 0,1,2,3 ; do taskset -pc
This is to check that the processor number is the only thing which matters
Sorry, I don't understand what does it mean, but here is the output (i have no isolcpus specified):
$ for i in 0 1 2 3 0,1,2,3 ; do taskset -pc
pid 25481's current affinity list: 0-3
pid 25481's new affinity list: 0
pid 25481's current affinity mask: 1
pid 25481's current affinity list: 0
pid 25481's new affinity list: 1
pid 25481's current affinity mask: 2
pid 25481's current affinity list: 1
pid 25481's new affinity list: 2
pid 25481's current affinity mask: 4
pid 25481's current affinity list: 2
pid 25481's new affinity list: 3
pid 25481's current affinity mask: 8
pid 25481's current affinity list: 3
pid 25481's new affinity list: 0-3
pid 25481's current affinity mask: f
I have made changes so the socket id, core id and thread id can be any number in any sequence in Version 1.5.1
Your output shows that the mask is 1 << processor/cpu id, i.e. there is no values to skip.
Just FYI. On the on Xeon (1 socket, 6 cores avaialbe for guest) in Xen-guest "core id" is always 0, "cpu cores" is always 1. So it will seem that this is a 6-socket machine.
On the Q6600 in Xen-guest (I assume so, not sure). both "core id" and "cpu cores" are completely absent for both available "processors" (physically Q6600 have 4 no-HT cores)
Can you give me the cpuinfo for the q6600 or add it to the src/test/resource/cpuinfo.q6600 ?
I have added more changes to support the i3. It should read the cpuinfo you gave me correctly. Add dumpLocksI3() prints
0: General use CPU
1: Thread[engine,5,main] alive=true
2: General use CPU
3: Thread[main,5,main] alive=false
The flags for the Q6600 report "ht" for hyper threading. I have seen mention that you can turn it on for some systems with a Q6600 and see 8 processors, but it was unclear to me if the author thought this should be the case, or it was something he knew to be the case.
The missing "core id", "physical id" fields appears to be OS flavour dependant
I will add support for the situation where these fields are not present. I will assume there is 1 socket and 1 thread per core.