I have an AMD Athlon64 X2 4400+ CPU (dual core, not SMT capable, so
two cores and two threads) - running a 32bit kernel.
Linux dragon 2.6.16-rc3-git7 #4 SMP PREEMPT Thu Feb 16 22:14:55 CET
2006 i686 athlon-4 i386 GNU/Linux
I just noticed that the number of core siblings reported through sysfs
is wrong. The number of thread siblings is correct and so is the info
reported via /proc/cpuinfo - only sysfs seems to get it wrong.
juhl@dragon:~$ cat /sys/devices/system/cpu/cpu1/topology/thread_siblings
2
juhl@dragon:~$ cat /sys/devices/system/cpu/cpu1/topology/core_siblings
3
two thread siblings makes perfect sense, but 3 core siblings?
Did my cores start to reproduce? - I know CPU's get hot, but I didn't
know that was the reason ;-)
Proc nicely reports 2 cores with same physical id and 2 siblings :
juhl@dragon:~$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 35
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
stepping : 2
cpu MHz : 2200.724
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
lm 3dnowext 3dnow pni lahf_lm cmp_legacy ts fid vid ttp
bogomips : 4405.02
processor : 1
vendor_id : AuthenticAMD
cpu family : 15
model : 35
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
stepping : 2
cpu MHz : 2200.724
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
lm 3dnowext 3dnow pni lahf_lm cmp_legacy ts fid vid ttp
bogomips : 4399.55
I tried adding some printk's to arch/i386/kernel/smpboot.c to see how
cpu_core_map got initialized, but couldn't spot any errors.
In set_cpu_sibling_map() there's a loop that runs for_each_cpu_mask(i,
cpu_sibling_setup_map) and does
cpu_set(i, cpu_core_map[cpu]);
cpu_set(cpu, cpu_core_map[i]);
I tried adding printk(KERN_WARNING "DEBUG: i = %d, cpu = %d\n", i, cpu);
just before those cpuset() calls, and that prints out
DEBUG: i = 0, cpu = 0
DEBUG: i = 0, cpu = 1
DEBUG: i = 1, cpu = 1
So we'll set bits 0 & 1 for each of the two cores in cpu_core_map[] ,
which looks sane to me.
So where does the extra core sibling come from that's reported via sysfs?
As far as I can tell, the
#define topology_core_siblings(cpu) (cpu_core_map[cpu])
in include/asm-i386/topology.h , will cause this bit of code :
#define define_siblings_show_func(name) \
static ssize_t show_##name(struct sys_device *dev, char *buf) \
{ \
ssize_t len = -1; \
unsigned int cpu = dev->id; \
len = cpumask_scnprintf(buf, NR_CPUS+1, topology_##name(cpu)); \
return (len + sprintf(buf + len, "\n")); \
}
...
#ifdef topology_core_siblings
define_siblings_show_func(core_siblings);
...
in drivers/base/topology.c to print out the nr of core siblings based
on what's in cpu_core_map - which as far as I can tell is OK.
Obviously something is wrong, but I just can't seem to spot it. Any clues?
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
