x86, x86_64: dual core proc-cpuinfo and sibling-map fix

PATCH In review Siddha, Suresh B 2 participants 2 messages Apr 12, 2005

lore

Share & tools

lore

Siddha, Suresh B

author

2005-04-12 05:56 UTC #0 lore raw

PATCH 1/1 x86, x86_64: dual core proc-cpuinfo and sibling-map fix

Appended patch fixes

- broken sibling_map setup in x86_64

- grouping all the core and HT related cpuinfo fields.
We are reasonably sure that adding new cpuinfo fields after "siblings" field, will not cause any app failure. Thats because today's /proc/cpuinfo format is completely different on x86, x86_64 and we haven't heard of any x86 app breakage because of this issue. Grouping these fields will result in more or less common format on all architectures (ia64, x86 and x86_64) and will cause less confusion.

Signed-off-by Suresh Siddha <[email protected]>

arch/i386/kernel/cpu/proc.c +2 -7

diff -Nru linux-2.6.12-rc2-mm3/arch/i386/kernel/cpu/proc.c linux-mc/arch/i386/kernel/cpu/proc.c
@@ -98,6 +98,8 @@
 		seq_printf(m, "physical id\t: %d\n", phys_proc_id[n]);
 		seq_printf(m, "siblings\t: %d\n",
 				c->x86_num_cores * smp_num_siblings);
+		seq_printf(m, "core id\t\t: %d\n", cpu_core_id[n]);
+		seq_printf(m, "cpu cores\t: %d\n", c->x86_num_cores);
 	}
 #endif

@@ -130,13 +132,6 @@
 		     c->loops_per_jiffy/(500000/HZ),
 		     (c->loops_per_jiffy/(5000/HZ)) % 100);
 
-#ifdef CONFIG_SMP
-	/* Put new fields at the end to lower the probability of
-	   breaking user space parsers. */
-	seq_printf(m, "core id\t\t: %d\n", cpu_core_id[n]);
-	seq_printf(m, "cpu cores\t: %d\n", c->x86_num_cores);
-#endif
-
 	return 0;
 }

arch/x86_64/kernel/setup.c +3 -8

diff -Nru linux-2.6.12-rc2-mm3/arch/x86_64/kernel/setup.c linux-mc/arch/x86_64/kernel/setup.c
@@ -1179,6 +1179,8 @@
 		seq_printf(m, "physical id\t: %d\n", phys_proc_id[cpu]);
 		seq_printf(m, "siblings\t: %d\n",
 				c->x86_num_cores * smp_num_siblings);
+		seq_printf(m, "core id\t\t: %d\n", cpu_core_id[cpu]);
+		seq_printf(m, "cpu cores\t: %d\n", c->x86_num_cores);
 	}
 #endif

@@ -1222,15 +1224,8 @@
 			}
 	}
 
-	seq_printf(m, "\n");
+	seq_printf(m, "\n\n");
 
-#ifdef CONFIG_SMP
-	/* Put new fields at the end to lower the probability of
-	   breaking user space parsers. */
-	seq_printf(m, "core id\t\t: %d\n", cpu_core_id[c - cpu_data]);
-	seq_printf(m, "cpu cores\t: %d\n", c->x86_num_cores);
-#endif
-	seq_printf(m, "\n");
 	return 0;
 }

arch/x86_64/kernel/smpboot.c +1 -1

diff -Nru linux-2.6.12-rc2-mm3/arch/x86_64/kernel/smpboot.c linux-mc/arch/x86_64/kernel/smpboot.c
@@ -652,7 +652,7 @@
 		int i;
 		if (smp_num_siblings > 1) {
 			for_each_online_cpu (i) {
-				if (cpu_core_id[cpu] == phys_proc_id[i]) {
+				if (cpu_core_id[cpu] == cpu_core_id[i]) {
 					siblings++;
 					cpu_set(i, cpu_sibling_map[cpu]);
 				}

Andi Kleen

2005-04-12 15:55 UTC #1 lore raw

Quoted 11 lines · Suresh B

Appended patch fixes
- broken sibling_map setup in x86_64
- grouping all the core and HT related cpuinfo fields.
We are reasonably sure that adding new cpuinfo fields after "siblings" field, will not cause any app failure. Thats because today's /proc/cpuinfo format is completely different on x86, x86_64 and we haven't heard of any x86 app breakage because of this issue. Grouping these fields will result in more or less common format on all architectures (ia64, x86 and x86_64) and will cause less confusion.

Ok from my side.

Andrew, please include that one in the batch going to Linus if there is still enough time.

-Andi