Agree. We can calculate smp_num_siblings from phys_proc_id[n] as the kernel
does, although it would be just nice or double-checking (but if the
application cannot calculate it correctly how can one expect it runs fine? I
mean it's very easy.)
So this is sufficient:
+#ifdef CONFIG_SMP
+ if (cpu_has_ht) {
+ seq_printf(m, "physical id\t: %d\n", phys_proc_id[n]);
+ }
+#endif
For a multi-core system, one could do:
seq_printf(m, "physical id\t: %d\n", phys_proc_id[n]);
seq_printf(m, "core id\t: %d\n", core_id[n]);
This would support multiple SMT processor cores on one chip. "core_id" is
the id of the CPU core in a chip die that the processor belongs to.
"physical_proc_id" is the id of the CPU die in the system.
Jun
-----Original Message-----
From: Dave Jones [mailto:davej@codemonkey.org.uk]
Sent: Friday, October 25, 2002 5:13 PM
To: Jeff Garzik
Cc: Robert Love; Nakajima, Jun; Alan Cox; 'akpm@digeo.com';
'linux-kernel@vger.kernel.org'; 'chrisl@vmware.com'; 'Martin J. Bligh'
Subject: Re: [PATCH] hyper-threading information in /proc/cpuinfo
On Fri, Oct 25, 2002 at 08:04:45PM -0400, Jeff Garzik wrote:
> Not really... we print out other information that is duplicated N times,
> because it is the common case that N-way systems have matched processors
> with matched capabilities.
Not really. We print out the 'duplicate' info because it's read that
way from different CPUs. The smp_num_siblings is a single global
variable. Theoretically, the other stuff /could/ change in an
asymetrical system, but the num_siblings thing is constant.
Dave
-- | Dave Jones. http://www.codemonkey.org.uk - 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/
This archive was generated by hypermail 2b29 : Thu Oct 31 2002 - 22:00:30 EST