RE: [PATCH] How to get number of physical CPU in linux from user space?

RE: [PATCH] How to get number of physical CPU in linux from user space?

[Nakajima, Jun]

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; akpm@digeo.com
Cc: linux-kernel@vger.kernel.org; Nakajima, Jun; chrisl@vmware.com;
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:rml@tech9.net]
Sent: Friday, October 25, 2002 12:21 PM
To: Dave Jones; akpm@digeo.com
Cc: linux-kernel@vger.kernel.org; Nakajima, Jun; chrisl@vmware.com;
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);

-
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/

[PATCH] hyper-threading information in /proc/cpuinfo

[Robert Love]

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;

Re: [PATCH] hyper-threading information in /proc/cpuinfo

[Robert Love]

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;

Re: [PATCH] hyper-threading information in /proc/cpuinfo

[Dave Jones]

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

Re: [PATCH] hyper-threading information in /proc/cpuinfo

[Jeff Garzik]

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

Re: [PATCH] hyper-threading information in /proc/cpuinfo

[Dave Jones]

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

Re: [PATCH] hyper-threading information in /proc/cpuinfo

[Jeff Garzik]

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

Re: [PATCH] hyper-threading information in /proc/cpuinfo

[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

RE: [PATCH] hyper-threading information in /proc/cpuinfo

[Nakajima, Jun]

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:alan@lxorguk.ukuu.org.uk]
Sent: Friday, October 25, 2002 3:15 PM
To: Nakajima, Jun
Cc: Robert Love; 'Dave Jones'; '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, 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 ?

-
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/

Re: [PATCH] hyper-threading information in /proc/cpuinfo

[J.A. Magallon]

On 2002.10.28 chrisl@vmware.com 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 <jamagallon@able.es>      \                 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))

Re: [PATCH] hyper-threading information in /proc/cpuinfo

[chrisl]

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:"october@surriel.com">october@surriel.com</a>
> 

Re: [PATCH] hyper-threading information in /proc/cpuinfo

[Rik van Riel]

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:"october@surriel.com">october@surriel.com</a>

Re: [PATCH] hyper-threading information in /proc/cpuinfo

[Eric W. Biederman]

Alan Cox <alan@lxorguk.ukuu.org.uk> 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

Re: [PATCH] hyper-threading information in /proc/cpuinfo

[Martin J. Bligh]

>> 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.

RE: [PATCH] hyper-threading information in /proc/cpuinfo

[Nakajima, Jun]

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'; 'akpm@digeo.com';
'linux-kernel@vger.kernel.org'; 'chrisl@vmware.com'; '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:riel@conectiva.com.br]
Sent: Friday, October 25, 2002 5:49 PM
To: Alan Cox
Cc: Nakajima, Jun; Robert Love; 'Dave Jones'; 'akpm@digeo.com';
'linux-kernel@vger.kernel.org'; 'chrisl@vmware.com'; '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:"october@surriel.com">october@surriel.com</a>

RE: [PATCH] hyper-threading information in /proc/cpuinfo

[Nakajima, Jun]

I don't understand. HT is one implementaion of (true) SMT. 

Thanks,
Jun

-----Original Message-----
From: Rik van Riel [mailto:riel@conectiva.com.br]
Sent: Friday, October 25, 2002 5:49 PM
To: Alan Cox
Cc: Nakajima, Jun; Robert Love; 'Dave Jones'; 'akpm@digeo.com';
'linux-kernel@vger.kernel.org'; 'chrisl@vmware.com'; '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:"october@surriel.com">october@surriel.com</a>

RE: [PATCH] hyper-threading information in /proc/cpuinfo

[Rik van Riel]

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:"october@surriel.com">october@surriel.com</a>

Re: [PATCH] hyper-threading information in /proc/cpuinfo

[J.A. Magallon]

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 <jamagallon@able.es>      \                 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))

Re: [PATCH] hyper-threading information in /proc/cpuinfo

[J.A. Magallon]

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 <jamagallon@able.es>      \                 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))

Re: [PATCH] hyper-threading information in /proc/cpuinfo

[Robert Love]

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

RE: [PATCH] hyper-threading information in /proc/cpuinfo

[Nakajima, Jun]

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

RE: [PATCH] hyper-threading information in /proc/cpuinfo

[Nakajima, Jun]

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:rml@tech9.net]
Sent: Friday, October 25, 2002 2:54 PM
To: Nakajima, Jun
Cc: Alan Cox; 'Dave Jones'; '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, 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

-
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/

Re: [PATCH] hyper-threading information in /proc/cpuinfo

[Daniel Phillips]

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

Re: [PATCH] hyper-threading information in /proc/cpuinfo

[Jeff Garzik]

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

Re: [PATCH] hyper-threading information in /proc/cpuinfo

[David D. Hagood]

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....

Re: [PATCH] hyper-threading information in /proc/cpuinfo

[Robert Love]

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

RE: [PATCH] hyper-threading information in /proc/cpuinfo

[Nakajima, Jun]

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:jgarzik@pobox.com]
Sent: Friday, October 25, 2002 3:58 PM
To: Nakajima, Jun
Cc: Robert Love; Daniel Phillips; Alan Cox; 'Dave Jones';
'akpm@digeo.com'; 'linux-kernel@vger.kernel.org'; 'chrisl@vmware.com';
'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

Re: [PATCH] hyper-threading information in /proc/cpuinfo

[David D. Hagood]

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....)

Re: [PATCH] hyper-threading information in /proc/cpuinfo

[Jeff Garzik]

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

RE: [PATCH] hyper-threading information in /proc/cpuinfo

[Nakajima, Jun]

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:jgarzik@pobox.com]
Sent: Friday, October 25, 2002 3:26 PM
To: Robert Love
Cc: Daniel Phillips; Alan Cox; Nakajima, Jun; 'Dave Jones';
'akpm@digeo.com'; 'linux-kernel@vger.kernel.org'; 'chrisl@vmware.com';
'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

Re: [PATCH] hyper-threading information in /proc/cpuinfo

[Jeff Garzik]

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

Re: [PATCH] hyper-threading information in /proc/cpuinfo

[chrisl]

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
> 

RE: [PATCH] hyper-threading information in /proc/cpuinfo

[Alan Cox]

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 ?

Re: [PATCH] hyper-threading information in /proc/cpuinfo

[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

Re: [PATCH] hyper-threading information in /proc/cpuinfo

[Daniel Phillips]

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

RE: [PATCH] hyper-threading information in /proc/cpuinfo

[Robert Love]

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

RE: [PATCH] hyper-threading information in /proc/cpuinfo

[Nakajima, Jun]

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:rml@tech9.net]
Sent: Friday, October 25, 2002 2:40 PM
To: Robert Love
Cc: Nakajima, Jun; Alan Cox; 'Dave Jones'; '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, 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;