Messages in this thread | | | Date | Thu, 16 Feb 2006 22:46:59 +0100 | From | Jesper Juhl <> | Subject | Wrong number of core_siblings in sysfs for Athlon64 X2 |
| |
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 <jesper.juhl@gmail.com> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |