You might want to remove __initdata (in smpboot.c):
int __initdata phys_proc_id[NR_CPUS];
Jun Nakajima
-----Original Message-----
From: Nakajima, Jun
Sent: Friday, October 25, 2002 12:49 PM
To: Robert Love; Dave Jones; [email protected]
Cc: [email protected]; Nakajima, Jun; [email protected];
Martin J. Bligh
Subject: RE: [PATCH] How to get number of physical CPU in linux from
user space?
One more request :-)
Actually "processor" keyword was not good in "physical processor ID"
(someone may be grepping it to find out the number of processors), and it
was one of the reasons it was changed/fixed in the AC tree.
Since (H/W) threads (rather than "siblings") in a CPU is generic (i.e. not
just an Intel thing), I would like to propose this ("physical id" is from
AC). Alan also simplified "number of simblings" to "siblings".
+#ifdef CONFIG_SMP
+ if (cpu_has_ht) {
+ seq_printf(m, "physical id\t: %d\n", phys_proc_id[n]);
+ seq_printf(m, "threads\t\t: %d\n", smp_num_siblings);
+ }
+#endif
Thanks,
Jun
-----Original Message-----
From: Robert Love [mailto:[email protected]]
Sent: Friday, October 25, 2002 12:21 PM
To: Dave Jones; [email protected]
Cc: [email protected]; Nakajima, Jun; [email protected];
Martin J. Bligh
Subject: Re: [PATCH] How to get number of physical CPU in linux from
user space?
On Fri, 2002-10-25 at 15:13, Dave Jones wrote:
> Should this be wrapped in a if (cpu_has_ht(c)) { } ?
> Seems silly to be displaying HT information on non-HT CPUs.
I am neutral, but is fine with me. It is just "cpu_has_ht", btw.
Take two...
This displays the physical processor id and number of siblings of each
processor in /proc/cpuinfo.
Robert Love
.proc.c.swp |binary
proc.c | 7 +++++++
2 files changed, 7 insertions(+)
diff -urN linux-2.5.44/arch/i386/kernel/cpu/proc.c
linux/arch/i386/kernel/cpu/proc.c
--- linux-2.5.44/arch/i386/kernel/cpu/proc.c 2002-10-19
00:02:29.000000000 -0400
+++ linux/arch/i386/kernel/cpu/proc.c 2002-10-25 15:18:03.000000000 -0400
@@ -17,6 +17,7 @@
* applications want to get the raw CPUID data, they should access
* /dev/cpu/<cpu_nr>/cpuid instead.
*/
+ extern int phys_proc_id[NR_CPUS];
static char *x86_cap_flags[] = {
/* Intel-defined */
"fpu", "vme", "de", "pse", "tsc", "msr", "pae", "mce",
@@ -74,6 +75,12 @@
/* Cache size */
if (c->x86_cache_size >= 0)
seq_printf(m, "cache size\t: %d KB\n", c->x86_cache_size);
+#ifdef CONFIG_SMP
+ if (cpu_has_ht) {
+ seq_printf(m, "physical processor ID\t: %d\n",
phys_proc_id[n]);
+ seq_printf(m, "number of siblings\t: %d\n",
smp_num_siblings);
+ }
+#endif
/* We use exception 16 if we have hardware math and we've either
seen it or the CPU claims it is internal */
fpu_exception = c->hard_math && (ignore_irq13 || cpu_has_fpu);
Take three. This patch displays hyper-threading information in
/proc/cpuinfo.
Changes since first post:
- wrap print in "if (cpu_has_ht) { ... }" (Dave Jones)
- remove initdata from phys_proc_id (Jun Nakajima)
- match field names in latest 2.4-ac (Alan Cox)
Patch is against 2.5.44.
Robert Love
cpu/proc.c | 7 +++++++
smpboot.c | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff -urN linux-2.5.44/arch/i386/kernel/cpu/proc.c linux/arch/i386/kernel/cpu/proc.c
--- linux-2.5.44/arch/i386/kernel/cpu/proc.c 2002-10-19 00:02:29.000000000 -0400
+++ linux/arch/i386/kernel/cpu/proc.c 2002-10-25 15:18:03.000000000 -0400
@@ -17,6 +17,7 @@
* applications want to get the raw CPUID data, they should access
* /dev/cpu/<cpu_nr>/cpuid instead.
*/
+ extern int phys_proc_id[NR_CPUS];
static char *x86_cap_flags[] = {
/* Intel-defined */
"fpu", "vme", "de", "pse", "tsc", "msr", "pae", "mce",
@@ -74,6 +75,12 @@
/* Cache size */
if (c->x86_cache_size >= 0)
seq_printf(m, "cache size\t: %d KB\n", c->x86_cache_size);
+#ifdef CONFIG_SMP
+ if (cpu_has_ht) {
+ seq_printf(m, "physical processor ID\t: %d\n", phys_proc_id[n]);
+ seq_printf(m, "number of siblings\t: %d\n", smp_num_siblings);
+ }
+#endif
/* We use exception 16 if we have hardware math and we've either seen it or the CPU claims it is internal */
fpu_exception = c->hard_math && (ignore_irq13 || cpu_has_fpu);
diff -urN linux-2.5.44/arch/i386/kernel/smpboot.c linux/arch/i386/kernel/smpboot.c
--- linux-2.5.44/arch/i386/kernel/smpboot.c 2002-10-19 00:01:53.000000000 -0400
+++ linux/arch/i386/kernel/smpboot.c 2002-10-25 17:24:26.000000000 -0400
@@ -58,7 +58,7 @@
/* Number of siblings per CPU package */
int smp_num_siblings = 1;
-int __initdata phys_proc_id[NR_CPUS]; /* Package ID of each logical CPU */
+int phys_proc_id[NR_CPUS]; /* Package ID of each logical CPU */
/* Bitmask of currently online CPUs */
unsigned long cpu_online_map;
On Fri, 2002-10-25 at 17:30, Robert Love wrote:
> - wrap print in "if (cpu_has_ht) { ... }" (Dave Jones)
> - remove initdata from phys_proc_id (Jun Nakajima)
> - match field names in latest 2.4-ac (Alan Cox)
missing this last bit, sorry..
Robert Love
cpu/proc.c | 7 +++++++
smpboot.c | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff -urN linux-2.5.44/arch/i386/kernel/cpu/proc.c linux/arch/i386/kernel/cpu/proc.c
--- linux-2.5.44/arch/i386/kernel/cpu/proc.c 2002-10-19 00:02:29.000000000 -0400
+++ linux/arch/i386/kernel/cpu/proc.c 2002-10-25 15:18:03.000000000 -0400
@@ -17,6 +17,7 @@
* applications want to get the raw CPUID data, they should access
* /dev/cpu/<cpu_nr>/cpuid instead.
*/
+ extern int phys_proc_id[NR_CPUS];
static char *x86_cap_flags[] = {
/* Intel-defined */
"fpu", "vme", "de", "pse", "tsc", "msr", "pae", "mce",
@@ -74,6 +75,12 @@
/* Cache size */
if (c->x86_cache_size >= 0)
seq_printf(m, "cache size\t: %d KB\n", c->x86_cache_size);
+#ifdef CONFIG_SMP
+ if (cpu_has_ht) {
+ seq_printf(m, "physical id\t: %d\n", phys_proc_id[n]);
+ seq_printf(m, "siblings\t: %d\n", smp_num_siblings);
+ }
+#endif
/* We use exception 16 if we have hardware math and we've either seen it or the CPU claims it is internal */
fpu_exception = c->hard_math && (ignore_irq13 || cpu_has_fpu);
diff -urN linux-2.5.44/arch/i386/kernel/smpboot.c linux/arch/i386/kernel/smpboot.c
--- linux-2.5.44/arch/i386/kernel/smpboot.c 2002-10-19 00:01:53.000000000 -0400
+++ linux/arch/i386/kernel/smpboot.c 2002-10-25 17:24:26.000000000 -0400
@@ -58,7 +58,7 @@
/* Number of siblings per CPU package */
int smp_num_siblings = 1;
-int __initdata phys_proc_id[NR_CPUS]; /* Package ID of each logical CPU */
+int phys_proc_id[NR_CPUS]; /* Package ID of each logical CPU */
/* Bitmask of currently online CPUs */
unsigned long cpu_online_map;
Sorry,
Can you please change "siblings\t" to "threads\t\t". SuSE 8.1, for example,
is already doing it:
+#ifdef CONFIG_SMP
+ if (cpu_has_ht) {
+ seq_printf(m, "physical id\t: %d\n", phys_proc_id[n]);
+ seq_printf(m, "threads\t\t: %d\n", smp_num_siblings);
+ }
+#endif
Thanks,
Jun
-----Original Message-----
From: Robert Love [mailto:[email protected]]
Sent: Friday, October 25, 2002 2:40 PM
To: Robert Love
Cc: Nakajima, Jun; Alan Cox; 'Dave Jones'; '[email protected]';
'[email protected]'; '[email protected]'; 'Martin J. Bligh'
Subject: Re: [PATCH] hyper-threading information in /proc/cpuinfo
On Fri, 2002-10-25 at 17:30, Robert Love wrote:
> - wrap print in "if (cpu_has_ht) { ... }" (Dave Jones)
> - remove initdata from phys_proc_id (Jun Nakajima)
> - match field names in latest 2.4-ac (Alan Cox)
missing this last bit, sorry..
Robert Love
cpu/proc.c | 7 +++++++
smpboot.c | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff -urN linux-2.5.44/arch/i386/kernel/cpu/proc.c
linux/arch/i386/kernel/cpu/proc.c
--- linux-2.5.44/arch/i386/kernel/cpu/proc.c 2002-10-19
00:02:29.000000000 -0400
+++ linux/arch/i386/kernel/cpu/proc.c 2002-10-25 15:18:03.000000000 -0400
@@ -17,6 +17,7 @@
* applications want to get the raw CPUID data, they should access
* /dev/cpu/<cpu_nr>/cpuid instead.
*/
+ extern int phys_proc_id[NR_CPUS];
static char *x86_cap_flags[] = {
/* Intel-defined */
"fpu", "vme", "de", "pse", "tsc", "msr", "pae", "mce",
@@ -74,6 +75,12 @@
/* Cache size */
if (c->x86_cache_size >= 0)
seq_printf(m, "cache size\t: %d KB\n", c->x86_cache_size);
+#ifdef CONFIG_SMP
+ if (cpu_has_ht) {
+ seq_printf(m, "physical id\t: %d\n", phys_proc_id[n]);
+ seq_printf(m, "siblings\t: %d\n", smp_num_siblings);
+ }
+#endif
/* We use exception 16 if we have hardware math and we've either
seen it or the CPU claims it is internal */
fpu_exception = c->hard_math && (ignore_irq13 || cpu_has_fpu);
diff -urN linux-2.5.44/arch/i386/kernel/smpboot.c
linux/arch/i386/kernel/smpboot.c
--- linux-2.5.44/arch/i386/kernel/smpboot.c 2002-10-19
00:01:53.000000000 -0400
+++ linux/arch/i386/kernel/smpboot.c 2002-10-25 17:24:26.000000000 -0400
@@ -58,7 +58,7 @@
/* Number of siblings per CPU package */
int smp_num_siblings = 1;
-int __initdata phys_proc_id[NR_CPUS]; /* Package ID of each logical CPU */
+int phys_proc_id[NR_CPUS]; /* Package ID of each logical CPU */
/* Bitmask of currently online CPUs */
unsigned long cpu_online_map;
On Fri, 2002-10-25 at 22:50, Nakajima, Jun wrote:
> Sorry,
>
> Can you please change "siblings\t" to "threads\t\t". SuSE 8.1, for example,
> is already doing it:
Could do
>
> +#ifdef CONFIG_SMP
> + if (cpu_has_ht) {
> + seq_printf(m, "physical id\t: %d\n", phys_proc_id[n]);
> + seq_printf(m, "threads\t\t: %d\n", smp_num_siblings);
> + }
> +#endif
Im just wondering what we would then use to describe a true multiple cpu
on a die x86. Im curious what the powerpc people think since they have
this kind of stuff - is there a generic terminology they prefer ?
On Fri, 2002-10-25 at 17:50, Nakajima, Jun wrote:
> Can you please change "siblings\t" to "threads\t\t". SuSE 8.1, for example,
> is already doing it:
But RedHat apparently is using siblings. 2.4-ac also uses siblings.
And I like "siblings" better so it wins in my opinion.
Robert Love
On Fri, 2002-10-25 at 18:06, Daniel Phillips wrote:
> On Saturday 26 October 2002 00:14, Alan Cox wrote:
>
> > Im just wondering what we would then use to describe a true multiple cpu
> > on a die x86. Im curious what the powerpc people think since they have
> > this kind of stuff - is there a generic terminology they prefer ?
>
> MIPS also has it, for N=2.
Yep, neat chip :)
POWER4 calls the technology "Chip-Multiprocessing (CMP)" but I have
never seen terminology for referring to the on-core processors
individually.
They do call the SMT units "threads" obviously, however, so if Alan is
OK with it maybe we should go with Jun's opinion and name the field
"thread" ?
Robert Love
On Saturday 26 October 2002 00:14, Alan Cox wrote:
> Im just wondering what we would then use to describe a true multiple cpu
> on a die x86. Im curious what the powerpc people think since they have
> this kind of stuff - is there a generic terminology they prefer ?
MIPS also has it, for N=2.
--
Daniel
I don't have a strong preference to pick up between this two.
But please stick to the same name when this come to an conclusion.
I hate to put code said if Redhat do this if SuSE do that
that kind of crap.
Thanks
Chris
PS, any idea will this available in 2.4 soon?
On Fri, Oct 25, 2002 at 05:54:26PM -0400, Robert Love wrote:
> On Fri, 2002-10-25 at 17:50, Nakajima, Jun wrote:
>
> > Can you please change "siblings\t" to "threads\t\t". SuSE 8.1, for example,
> > is already doing it:
>
> But RedHat apparently is using siblings. 2.4-ac also uses siblings.
> And I like "siblings" better so it wins in my opinion.
>
> Robert Love
>
Robert Love wrote:
>On Fri, 2002-10-25 at 18:06, Daniel Phillips wrote:
>
>
>
>>On Saturday 26 October 2002 00:14, Alan Cox wrote:
>>
>>
>>
>>>Im just wondering what we would then use to describe a true multiple cpu
>>>on a die x86. Im curious what the powerpc people think since they have
>>>this kind of stuff - is there a generic terminology they prefer ?
>>>
>>>
>>MIPS also has it, for N=2.
>>
>>
>
>Yep, neat chip :)
>
>POWER4 calls the technology "Chip-Multiprocessing (CMP)" but I have
>never seen terminology for referring to the on-core processors
>individually.
>
>They do call the SMT units "threads" obviously, however, so if Alan is
>OK with it maybe we should go with Jun's opinion and name the field
>"thread" ?
>
>
"thread" already has another use. Let's not let the idiocy [most
likely] perpetrated by marketing folks to filter down to the useful
technical level. :)
Sorta like Intel and their re-re-use of "IPF." It's only going to
increase confusion.
Jeff
The notion of "SMT (Simultaneous Multi-Threaded)" architecture has been
there for a while (at least 8 years, as far as I know). You would get tons
of info if you search it in Internet.
Jun
-----Original Message-----
From: Jeff Garzik [mailto:[email protected]]
Sent: Friday, October 25, 2002 3:26 PM
To: Robert Love
Cc: Daniel Phillips; Alan Cox; Nakajima, Jun; 'Dave Jones';
'[email protected]'; '[email protected]'; '[email protected]';
'Martin J. Bligh'
Subject: Re: [PATCH] hyper-threading information in /proc/cpuinfo
Robert Love wrote:
>On Fri, 2002-10-25 at 18:06, Daniel Phillips wrote:
>
>
>
>>On Saturday 26 October 2002 00:14, Alan Cox wrote:
>>
>>
>>
>>>Im just wondering what we would then use to describe a true multiple cpu
>>>on a die x86. Im curious what the powerpc people think since they have
>>>this kind of stuff - is there a generic terminology they prefer ?
>>>
>>>
>>MIPS also has it, for N=2.
>>
>>
>
>Yep, neat chip :)
>
>POWER4 calls the technology "Chip-Multiprocessing (CMP)" but I have
>never seen terminology for referring to the on-core processors
>individually.
>
>They do call the SMT units "threads" obviously, however, so if Alan is
>OK with it maybe we should go with Jun's opinion and name the field
>"thread" ?
>
>
"thread" already has another use. Let's not let the idiocy [most
likely] perpetrated by marketing folks to filter down to the useful
technical level. :)
Sorta like Intel and their re-re-use of "IPF." It's only going to
increase confusion.
Jeff
Nakajima, Jun wrote:
>The notion of "SMT (Simultaneous Multi-Threaded)" architecture has been
>there for a while (at least 8 years, as far as I know). You would get tons
>of info if you search it in Internet.
>
>
Certainly. That however does not imply that Robert's patch should read
"number of threads" instead of "number of siblings." The lone word
"thread" does not automatically imply "active thread running on this
virtual processor" or anything close to that.
"sibling" makes a lot more sense from an English language perspective.
Jeff
Jeff Garzik wrote:
>
> "sibling" makes a lot more sense from an English language perspective.
>
Might I suggest "subcore", since that's really what it is - a sub-core
in the main chip.
My siblings are distinct entities from me, my sub-parts aren't.
(now, were I part of a cojoined twin....)
No, the notion of "sibling" is not clear. The other day a person pointed out
"the number of the siblings does not include yourself" when she saw the
variable smp_num_siblings. So with HT enabled, for a cpu the number of the
siblings should be 1, instead of 2, from an English language perspective.
But we want to mean the number H/W threads in a processor package.
And with multi-core, "sibling" is not clear enough to distiguish "core" in a
processor package and "thread" in a "core".
Jun
-----Original Message-----
From: Jeff Garzik [mailto:[email protected]]
Sent: Friday, October 25, 2002 3:58 PM
To: Nakajima, Jun
Cc: Robert Love; Daniel Phillips; Alan Cox; 'Dave Jones';
'[email protected]'; '[email protected]'; '[email protected]';
'Martin J. Bligh'
Subject: Re: [PATCH] hyper-threading information in /proc/cpuinfo
Nakajima, Jun wrote:
>The notion of "SMT (Simultaneous Multi-Threaded)" architecture has been
>there for a while (at least 8 years, as far as I know). You would get tons
>of info if you search it in Internet.
>
>
Certainly. That however does not imply that Robert's patch should read
"number of threads" instead of "number of siblings." The lone word
"thread" does not automatically imply "active thread running on this
virtual processor" or anything close to that.
"sibling" makes a lot more sense from an English language perspective.
Jeff
On Fri, 2002-10-25 at 19:21, David D. Hagood wrote:
> Might I suggest "subcore", since that's really what it is - a sub-core
> in the main chip.
>
> My siblings are distinct entities from me, my sub-parts aren't.
> (now, were I part of a cojoined twin....)
Sibling makes sense if you look at the N processors in the package as
"siblings of each other" i.e. not a hierarchy (as subcore implies) but
just a "set of virtual processors in the same core".
If there are subcores, then I think there must be some major core. If
two chips are siblings, then that merely says they are related (in this
case, the same parent package).
Robert Love
Nakajima, Jun wrote:
>No, the notion of "sibling" is not clear. The other day a person pointed out
>"the number of the siblings does not include yourself" when she saw the
>variable smp_num_siblings. So with HT enabled, for a cpu the number of the
>siblings should be 1, instead of 2, from an English language perspective.
>But we want to mean the number H/W threads in a processor package.
>
>And with multi-core, "sibling" is not clear enough to distiguish "core" in a
>processor package and "thread" in a "core".
>
>
That's fine. I can be convinced away from "sibling", I'll leave that up
to others. Personally I think I prefer "virtual core" over "sibling"
and "sub-core".
However, "thread" is the least clear of the proposed choices, and should
not be used. Anything-but-thread is my position :) Thread is used to
describe processes in Linux, those active in hardware and also those
sleeping in memory, etc.
Jeff
Robert Love wrote:
>
> If there are subcores, then I think there must be some major core.
I would assert that, at least in the case of the P4, there IS a "major
core", as the 2 subcores share L1 and bus controller access, as well as
several other parts of the chip.
I beleive this is to some extent the case in the Power4 modules - that
each module contains resources shared by the execution units. However, I
might be full of it, and since there are plenty of @ibm.com's here I
expect to be corrected shortly....
On Saturday 26 October 2002 00:42, Nakajima, Jun wrote:
> The notion of "SMT (Simultaneous Multi-Threaded)" architecture has been
> there for a while (at least 8 years, as far as I know). You would get tons
> of info if you search it in Internet.
Actually, what we were referring to is multiple complete, separate
processor cores on one chip. Two complete cores turns in true 2X
performance, modulo cache effects, vs SMT which turns in anywhere
from 0 to 20% improvement.
MIPS does 2X processors/chip, and IBM is planning to do 32X. I've
heard rumours of 128X as well.
--
Daniel
Dave Jones wrote:
>On Fri, Oct 25, 2002 at 05:30:19PM -0400, Robert Love wrote:
>
> > +#ifdef CONFIG_SMP
> > + if (cpu_has_ht) {
> > + seq_printf(m, "physical processor ID\t: %d\n", phys_proc_id[n]);
> > + seq_printf(m, "number of siblings\t: %d\n", smp_num_siblings);
> > + }
> > +#endif
>
>Something else looks suspect to me here.
>smp_num_siblings is going to say the same value on every CPU in the
>system. It's questionable whether we want to print it out n times.
>
>
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. The above caught my eye as well, but the
alternative is to subvert the standard /proc/cpuinfo format and print
something out only once, that clearly applies to each processor.
Jeff
On Fri, Oct 25, 2002 at 05:30:19PM -0400, Robert Love wrote:
> +#ifdef CONFIG_SMP
> + if (cpu_has_ht) {
> + seq_printf(m, "physical processor ID\t: %d\n", phys_proc_id[n]);
> + seq_printf(m, "number of siblings\t: %d\n", smp_num_siblings);
> + }
> +#endif
Something else looks suspect to me here.
smp_num_siblings is going to say the same value on every CPU in the
system. It's questionable whether we want to print it out n times.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
RedHat 8.0 is using
"Physical processor ID\t:"
"Number of siblings\t:"
This implies they need to change it anyway, because 2.4-ac is
"physical id\t:"
"siblings\t:"
Jun
-----Original Message-----
From: Robert Love [mailto:[email protected]]
Sent: Friday, October 25, 2002 2:54 PM
To: Nakajima, Jun
Cc: Alan Cox; 'Dave Jones'; '[email protected]';
'[email protected]'; '[email protected]'; 'Martin J. Bligh'
Subject: RE: [PATCH] hyper-threading information in /proc/cpuinfo
On Fri, 2002-10-25 at 17:50, Nakajima, Jun wrote:
> Can you please change "siblings\t" to "threads\t\t". SuSE 8.1, for
example,
> is already doing it:
But RedHat apparently is using siblings. 2.4-ac also uses siblings.
And I like "siblings" better so it wins in my opinion.
Robert Love
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
Dave Jones wrote:
>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.
>
>
Sure, but you snipped the other part of the argument :) Printing stuff
only once is changes the format which has previously been to print out
the same fields [but not necessarily the same values] for each CPU; so
the alternative is to create /proc/global_cpu_info just to print out
num-siblings only once :) IOW, I don't see it as a big deal to print
out the duplicated info, because that maintains the other assumptions
about output format.
That said, on IRC my preference was to create smp_num_siblings[] and
store the info per-cpu. But right now that's only for software
engineering masturbation :) since it would store the same value N times
on current CPUs.
Jeff
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:[email protected]]
Sent: Friday, October 25, 2002 5:13 PM
To: Jeff Garzik
Cc: Robert Love; Nakajima, Jun; Alan Cox; '[email protected]';
'[email protected]'; '[email protected]'; '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
On Fri, 2002-10-25 at 19:45, David D. Hagood wrote:
> I would assert that, at least in the case of the P4, there IS a "major
> core", as the 2 subcores share L1 and bus controller access, as well as
> several other parts of the chip.
>
> I beleive this is to some extent the case in the Power4 modules - that
> each module contains resources shared by the execution units. However, I
> might be full of it, and since there are plenty of @ibm.com's here I
> expect to be corrected shortly....
You are entirely right :)
But argument for siblings vs. subcore is that in the context of the
processors displayed in /proc/cpuinfo known of them are "subscores" of
the other (and thus none of them are the "main core").
Some are just "siblings" in the same parent process package. So given a
dual Xeon machine, you have 4 virtual processors, which are broken into
two sets of two siblings. Those two sets are each part of the same
package.
Robert Love
On Fri, 2002-10-25 at 20:16, Jeff Garzik wrote:
> That said, on IRC my preference was to create smp_num_siblings[] and
> store the info per-cpu. But right now that's only for software
> engineering masturbation :) since it would store the same value N times
> on current CPUs.
I agree with Jeff here - mostly because subverting the format is no
good, either.
In the future, or perhaps on other architectures, smp_num_siblings could
be per-processor. So now we can extend this in the future and not break
the /proc interface.
Its just a by-product of the P4 that smp_num_siblings is global on
arch-i386.
Robert Love
On 2002.10.26 "Nakajima, Jun" wrote:
>RedHat 8.0 is using
> "Physical processor ID\t:"
> "Number of siblings\t:"
>This implies they need to change it anyway, because 2.4-ac is
> "physical id\t:"
> "siblings\t:"
>
Summary:
- we have processor packages
- each package can handle several (someone said 128+ ;) ) processor cores.
We really do not mind if they are really independent (power4) or not
(xeon, ht)
- each core is a logical unit for Linux
- can we have two packages with different number of cores ?
Proposal for /proc/cpuinfo (sample box: an hypothetical TurboPower4 with
4 cores, 2 units on an SMP box):
processor : 0 processor : 2 processor : 4 processor : 6
package : 0 package : 0 package : 0 package : 0
core : 0 core : 1 core : 2 core : 3
processor : 1 processor : 3 processor : 5 processor : 7
package : 1 package : 1 package : 1 package : 1
core : 0 core : 1 core : 2 core : 3
So you can look for siblings based on package number, you can know if
two precessors are in different packages (for sched...), etc.
NOTE: do not know if 'core' name can give problems, perhaps you could use
'unit' instead.
--
J.A. Magallon <[email protected]> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.1 (Cooker) for i586
Linux 2.4.20-pre11-jam2 (gcc 3.2 (Mandrake Linux 9.0 3.2-2mdk))
On 25 Oct 2002, Alan Cox wrote:
> On Fri, 2002-10-25 at 22:50, Nakajima, Jun wrote:
> > Can you please change "siblings\t" to "threads\t\t". SuSE 8.1, for example,
> > is already doing it:
> Im just wondering what we would then use to describe a true multiple cpu
> on a die x86. Im curious what the powerpc people think since they have
> this kind of stuff - is there a generic terminology they prefer ?
Agreed. Siblings is probably best for HT stuff and threads
are probably best reserved for true SMT CPUs.
Then there's the SMP-on-a-chip, but we should probably just
call those CPUs.
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>
On 2002.10.26 J.A. Magallon wrote:
>
>processor : 0 processor : 2 processor : 4 processor : 6
>package : 0 package : 0 package : 0 package : 0
>core : 0 core : 1 core : 2 core : 3
>
>processor : 1 processor : 3 processor : 5 processor : 7
>package : 1 package : 1 package : 1 package : 1
>core : 0 core : 1 core : 2 core : 3
>
Er, while you're at it, would it be worthy to add ad:
node: x
for NUMA boxes ?
(just a silly idea)
--
J.A. Magallon <[email protected]> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.1 (Cooker) for i586
Linux 2.4.20-pre11-jam2 (gcc 3.2 (Mandrake Linux 9.0 3.2-2mdk))
I don't understand. HT is one implementaion of (true) SMT.
Thanks,
Jun
-----Original Message-----
From: Rik van Riel [mailto:[email protected]]
Sent: Friday, October 25, 2002 5:49 PM
To: Alan Cox
Cc: Nakajima, Jun; Robert Love; 'Dave Jones'; '[email protected]';
'[email protected]'; '[email protected]'; 'Martin J. Bligh'
Subject: RE: [PATCH] hyper-threading information in /proc/cpuinfo
On 25 Oct 2002, Alan Cox wrote:
> On Fri, 2002-10-25 at 22:50, Nakajima, Jun wrote:
> > Can you please change "siblings\t" to "threads\t\t". SuSE 8.1, for
example,
> > is already doing it:
> Im just wondering what we would then use to describe a true multiple cpu
> on a die x86. Im curious what the powerpc people think since they have
> this kind of stuff - is there a generic terminology they prefer ?
Agreed. Siblings is probably best for HT stuff and threads
are probably best reserved for true SMT CPUs.
Then there's the SMP-on-a-chip, but we should probably just
call those CPUs.
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Current spamtrap: <a
href=mailto:"[email protected]">[email protected]</a>
I mean what you were referring to is called Chip-Multiprocessor (CMP),
architecturally. And probably, this is the cause of the confusion in the
discussions.
SMT is an orthogonal to it, and it is an established notion. You can have
SMT CMP, for example. So using "thread" for the cores in CMP is not proper
wording. It sounds something like "core" to me.
In my mind, the processor hierarchy looks like:
node
package (chip die)
core
thread
Jun
-----Original Message-----
From: Nakajima, Jun
Sent: Friday, October 25, 2002 5:54 PM
To: 'Rik van Riel'; Alan Cox
Cc: Nakajima, Jun; Robert Love; 'Dave Jones'; '[email protected]';
'[email protected]'; '[email protected]'; 'Martin J. Bligh'
Subject: RE: [PATCH] hyper-threading information in /proc/cpuinfo
I don't understand. HT is one implementaion of (true) SMT.
Thanks,
Jun
-----Original Message-----
From: Rik van Riel [mailto:[email protected]]
Sent: Friday, October 25, 2002 5:49 PM
To: Alan Cox
Cc: Nakajima, Jun; Robert Love; 'Dave Jones'; '[email protected]';
'[email protected]'; '[email protected]'; 'Martin J. Bligh'
Subject: RE: [PATCH] hyper-threading information in /proc/cpuinfo
On 25 Oct 2002, Alan Cox wrote:
> On Fri, 2002-10-25 at 22:50, Nakajima, Jun wrote:
> > Can you please change "siblings\t" to "threads\t\t". SuSE 8.1, for
example,
> > is already doing it:
> Im just wondering what we would then use to describe a true multiple cpu
> on a die x86. Im curious what the powerpc people think since they have
> this kind of stuff - is there a generic terminology they prefer ?
Agreed. Siblings is probably best for HT stuff and threads
are probably best reserved for true SMT CPUs.
Then there's the SMP-on-a-chip, but we should probably just
call those CPUs.
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Current spamtrap: <a
href=mailto:"[email protected]">[email protected]</a>
>> processor : 0 processor : 2 processor : 4 processor : 6
>> package : 0 package : 0 package : 0 package : 0
>> core : 0 core : 1 core : 2 core : 3
>>
>> processor : 1 processor : 3 processor : 5 processor : 7
>> package : 1 package : 1 package : 1 package : 1
>> core : 0 core : 1 core : 2 core : 3
>>
>
> Er, while you're at it, would it be worthy to add ad:
>
> node: x
>
> for NUMA boxes ?
We also need to indicate other things here though, which is why
Matt Dobson implemented a more complete topology description
under driverfs. If you're really interested in that level of
detail from userspace, you probably also want to know things
like whether the evil twins share a TLB cache or L1/L2 cache.
I can't help feeling that's the more correct & complete solution
to the problem. His patches are in the latest -mm tree, and would
need some more work to be extended to hyperthreading, but that
seems like the better way (for 2.5 at least).
M.
Alan Cox <[email protected]> writes:
> On Fri, 2002-10-25 at 22:50, Nakajima, Jun wrote:
> > Sorry,
> >
> > Can you please change "siblings\t" to "threads\t\t". SuSE 8.1, for example,
> > is already doing it:
>
> Could do
> >
> > +#ifdef CONFIG_SMP
> > + if (cpu_has_ht) {
> > + seq_printf(m, "physical id\t: %d\n", phys_proc_id[n]);
> > + seq_printf(m, "threads\t\t: %d\n", smp_num_siblings);
> > + }
> > +#endif
>
>
> Im just wondering what we would then use to describe a true multiple cpu
> on a die x86. Im curious what the powerpc people think since they have
> this kind of stuff - is there a generic terminology they prefer ?
How about using "SMT width" for the P4 case?
And if we needed to break it down per package for a Power4 and the
like we could talk about CMP something, or other.
Only SMT and CMP seem to be unambiguous prefixes. Though for CMP
we probably do not need to do anything because it really is 2 cpus, and we
only need to worry about locatity in the cache hierarchy not the fact that
if we schedule a cpu intensive job on 1 ``cpu'' the others are useless.
Eric
On Sat, 26 Oct 2002, J.A. Magallon wrote:
> Summary:
> - each package can handle several (someone said 128+ ;) ) processor cores.
> We really do not mind if they are really independent (power4) or not
> (xeon, ht)
Here is the big opinion of difference. Apparently people _do_
care, otherwise they would have never asked for HT evil twins
to be reported separately in /proc.
kind regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>
Yes, we care about that because vmware see a different CPU number from
the one reported by the customer. And HT twins cpu is consider 1.3x
instead of 2x.
Cheers
Chris
On Sat, Oct 26, 2002 at 05:48:11PM -0200, Rik van Riel wrote:
> On Sat, 26 Oct 2002, J.A. Magallon wrote:
>
> > Summary:
>
> > - each package can handle several (someone said 128+ ;) ) processor cores.
> > We really do not mind if they are really independent (power4) or not
> > (xeon, ht)
>
> Here is the big opinion of difference. Apparently people _do_
> care, otherwise they would have never asked for HT evil twins
> to be reported separately in /proc.
>
> kind regards,
>
> Rik
> --
> Bravely reimplemented by the knights who say "NIH".
> http://www.surriel.com/ http://distro.conectiva.com/
> Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>
>
On 2002.10.28 [email protected] wrote:
>Yes, we care about that because vmware see a different CPU number from
>the one reported by the customer. And HT twins cpu is consider 1.3x
>instead of 2x.
>
Perhaps what is really needed is a memory hierarchy in /proc (or elsewhere)
that enumerates its associated processors:
/proc/mem/
/node0..n
/main => processors: 0 1 2 3
/cache/
cache0 => processors: 0 2
cache1 => processors: 1 2
As I understand, many times ypu want to put a process in some processor
based on its sharing (or independence) of some memory level (numa local
preference, or hyperthreading)...
--
J.A. Magallon <[email protected]> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.1 (Cooker) for i586
Linux 2.4.20-pre11-jam2 (gcc 3.2 (Mandrake Linux 9.0 3.2-2mdk))
Looks like they don't want us to use "threads" for various reasons. Those
could be even religious/branding issues, which I have no interests in. My
interest is to have consistent format/info for HT cpuinfo among the kernels.
So can you please change like:
+#ifdef CONFIG_SMP
+ if (cpu_has_ht) {
+ seq_printf(m, "physical id\t: %d\n", phys_proc_id[n]);
+ seq_printf(m, "logical cpus\t: %d per package\n",
smp_num_siblings);
+ }
+#endif
This is consistent with the spec/manual from Intel. They use logical
processor (and thread :-), physical processor, physical package, etc.
Thanks,
Jun
-----Original Message-----
From: Alan Cox [mailto:[email protected]]
Sent: Friday, October 25, 2002 3:15 PM
To: Nakajima, Jun
Cc: Robert Love; 'Dave Jones'; '[email protected]';
'[email protected]'; '[email protected]'; 'Martin J. Bligh'
Subject: RE: [PATCH] hyper-threading information in /proc/cpuinfo
On Fri, 2002-10-25 at 22:50, Nakajima, Jun wrote:
> Sorry,
>
> Can you please change "siblings\t" to "threads\t\t". SuSE 8.1, for
example,
> is already doing it:
Could do
>
> +#ifdef CONFIG_SMP
> + if (cpu_has_ht) {
> + seq_printf(m, "physical id\t: %d\n", phys_proc_id[n]);
> + seq_printf(m, "threads\t\t: %d\n", smp_num_siblings);
> + }
> +#endif
Im just wondering what we would then use to describe a true multiple cpu
on a die x86. Im curious what the powerpc people think since they have
this kind of stuff - is there a generic terminology they prefer ?