It seems that /proc/cpuinfo will return the number of logical CPU.
If the machine has Intel Hyper-Thread enabled, that number is bigger
than physical CPU number. Usually twice as big.
My question is, what is the reliable way for user space program
to detect the number of physical CPU in the current machine?
If in it is in the kernel, I can read from cpu_sibling_map[]
or phys_cpu_id[]. But it seems not easy read that from
user space.
Of course I can do "gdb /proc/kcore" to get them. But is there
any better way?
Thanks in advance.
Chris
I rebuilt 2.5.44 with the ACPI stuff enabled, and I see 2 cpus in
/proc/cpuinfo:
daedalus@hercules daedalus $ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) XEON(TM) CPU 2.20GHz
stepping : 4
cpu MHz : 2200.469
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 4341.76
processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) XEON(TM) CPU 2.20GHz
stepping : 4
cpu MHz : 2200.469
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 4390.91
Also dmesg says:
daedalus@hercules daedalus $ dmesg
1462.55 usecs.
task migration cache decay timeout: 2 msecs.
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Booting processor 1/1 eip 2000
Initializing CPU#1
masked ExtINT on CPU#1
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Calibrating delay loop... 4390.91 BogoMIPS
CPU: Before vendor init, caps: 3febfbff 00000000 00000000, vendor = 0
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
CPU: After vendor init, caps: 3febfbff 00000000 00000000 00000000
Intel machine check reporting enabled on CPU#1.
CPU#1: Intel P4/Xeon Extended MCE MSRs (12) available
CPU#1: Thermal monitoring enabled
CPU: After generic, caps: 3febfbff 00000000 00000000 00000000
CPU: Common caps: 3febfbff 00000000 00000000 00000000
CPU1: Intel(R) XEON(TM) CPU 2.20GHz stepping 04
Total of 2 processors activated (8732.67 BogoMIPS).
And a bit further down...
checking TSC synchronization across 2 CPUs: passed.
Starting migration thread for cpu 0
Bringing up 1
CPU 1 IS NOW UP!
Starting migration thread for cpu 1
CPUS done 4294967295
And down some more we seem to have 4 cpus...
ACPI: Processor [CPU0] (supports C1)
ACPI: Processor [CPU1] (supports C1)
ACPI: Processor [CPU2] (supports C1)
ACPI: Processor [CPU3] (supports C1)
I think with ACPI disabled I had 4 processors listed in /proc/cpuinfo,
but I'll check.
[email protected] wrote:
>It seems that /proc/cpuinfo will return the number of logical CPU.
>If the machine has Intel Hyper-Thread enabled, that number is bigger
>than physical CPU number. Usually twice as big.
>
>My question is, what is the reliable way for user space program
>to detect the number of physical CPU in the current machine?
>
>If in it is in the kernel, I can read from cpu_sibling_map[]
>or phys_cpu_id[]. But it seems not easy read that from
>user space.
>
>Of course I can do "gdb /proc/kcore" to get them. But is there
>any better way?
>
>Thanks in advance.
>
>Chris
>
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
On Fri, 2002-10-25 at 00:02, [email protected] wrote:
> It seems that /proc/cpuinfo will return the number of logical CPU.
> If the machine has Intel Hyper-Thread enabled, that number is bigger
> than physical CPU number. Usually twice as big.
>
> My question is, what is the reliable way for user space program
> to detect the number of physical CPU in the current machine?
I believe there was talk about representing the CPUs in driverfs
somehow. Not sure of the details though...
--
// Gianni Tedesco (gianni at ecsc dot co dot uk)
lynx --source http://www.scaramanga.co.uk/gianni-at-ecsc.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D
Define "physical CPU number" ;-) If you want to deteact which
ones are paired up, I believe that if all but the last bit
of the apicid is the same, they're siblings. You might have to
dig the apicid out of the bootlog if the cpuinfo stuff doesn't
tell you.
M.
--On Thursday, October 24, 2002 4:02 PM -0700 [email protected] wrote:
> It seems that /proc/cpuinfo will return the number of logical CPU.
> If the machine has Intel Hyper-Thread enabled, that number is bigger
> than physical CPU number. Usually twice as big.
>
> My question is, what is the reliable way for user space program
> to detect the number of physical CPU in the current machine?
>
> If in it is in the kernel, I can read from cpu_sibling_map[]
> or phys_cpu_id[]. But it seems not easy read that from
> user space.
>
> Of course I can do "gdb /proc/kcore" to get them. But is there
> any better way?
>
> Thanks in advance.
>
> Chris
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
On Thu, Oct 24, 2002 at 04:02:29PM -0700, [email protected] wrote:
> It seems that /proc/cpuinfo will return the number of logical CPU.
> If the machine has Intel Hyper-Thread enabled, that number is bigger
> than physical CPU number. Usually twice as big.
>
> My question is, what is the reliable way for user space program
> to detect the number of physical CPU in the current machine?
>
> If in it is in the kernel, I can read from cpu_sibling_map[]
> or phys_cpu_id[]. But it seems not easy read that from
> user space.
>
> Of course I can do "gdb /proc/kcore" to get them. But is there
> any better way?
You can perform cpuid instructions in userspace to get the
number of siblings per physical package.
--
| Dave Jones. http://www.codemonkey.org.uk
On Fri, Oct 25, 2002 at 01:27:00AM -0700, Martin J. Bligh wrote:
> Define "physical CPU number" ;-) If you want to deteact which
I mean the number of cpu chip you can count on the mother board.
> ones are paired up, I believe that if all but the last bit
> of the apicid is the same, they're siblings. You might have to
> dig the apicid out of the bootlog if the cpuinfo stuff doesn't
> tell you.
And you are right. Those apicid, after mask out the siblings,
are put in phys_cpu_id[] array in kernel.
I think about look at bootlog too, but that is not a reliable
way because bootlog might already been flush out after some
time.
Cheers
Chris
[email protected] wrote:
>On Fri, Oct 25, 2002 at 01:27:00AM -0700, Martin J. Bligh wrote:
>
>
>>Define "physical CPU number" ;-) If you want to deteact which
>>
>>
>
>I mean the number of cpu chip you can count on the mother board.
>
>
>
>>ones are paired up, I believe that if all but the last bit
>>of the apicid is the same, they're siblings. You might have to
>>dig the apicid out of the bootlog if the cpuinfo stuff doesn't
>>tell you.
>>
>>
>
>And you are right. Those apicid, after mask out the siblings,
>are put in phys_cpu_id[] array in kernel.
>
>I think about look at bootlog too, but that is not a reliable
>way because bootlog might already been flush out after some
>time.
>
>Cheers
>
>Chris
>
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
Here is what RedHat does in some of their SRPMS to check if you have
multiple CPUs on your build machine so they can do some parallel builds
to speed up the build process (kernel, glibc, etc):
egrep -c "^cpu[0-9]+" /proc/stat || :
Recent distributions or the AC tree has additional fields in /proc/cpu,
which tell
- physical package id
- number of threads
for each CPU.
Using this info, you should be able to detect it. The problem is that they
are not using the same keywords. I'm asking them to make those fields
consistent.
Thanks,
Jun
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Friday, October 25, 2002 11:20 AM
To: Martin J. Bligh
Cc: [email protected]
Subject: Re: How to get number of physical CPU in linux from user space?
On Fri, Oct 25, 2002 at 01:27:00AM -0700, Martin J. Bligh wrote:
> Define "physical CPU number" ;-) If you want to deteact which
I mean the number of cpu chip you can count on the mother board.
> ones are paired up, I believe that if all but the last bit
> of the apicid is the same, they're siblings. You might have to
> dig the apicid out of the bootlog if the cpuinfo stuff doesn't
> tell you.
And you are right. Those apicid, after mask out the siblings,
are put in phys_cpu_id[] array in kernel.
I think about look at bootlog too, but that is not a reliable
way because bootlog might already been flush out after some
time.
Cheers
Chris
>> ones are paired up, I believe that if all but the last bit
>> of the apicid is the same, they're siblings. You might have to
>> dig the apicid out of the bootlog if the cpuinfo stuff doesn't
>> tell you.
>
> And you are right. Those apicid, after mask out the siblings,
> are put in phys_cpu_id[] array in kernel.
Probably best to just hack /proc/cpuinfo output to include the apicid.
M.
On Fri, Oct 25, 2002 at 01:38:57PM +0100, Dave Jones wrote:
>
> You can perform cpuid instructions in userspace to get the
> number of siblings per physical package.
>
Sure. But the problem is that we don't know for sure how many
of the sibling was enable in the kernel. Kernel support up to
2 siblings right now, but it might be more in later kernel. And
user might turn off sibling in kernel.
So divide the number of cpu in cpuinfo by number of siblings per
physical package do not work reliable.
Any comment to add one entry into /proc/cpuinfo to tell which physical
cpu it belong to? I don't mind submit a patch. It will be something
look like:
processor : 2
physical cpu : 1
Cheers
Chris
I meant /proc/cpuinfo
Thanks,
Jun
-----Original Message-----
From: Nakajima, Jun
Sent: Friday, October 25, 2002 11:53 AM
To: '[email protected]'; Martin J. Bligh
Cc: [email protected]
Subject: RE: How to get number of physical CPU in linux from user space?
Recent distributions or the AC tree has additional fields in /proc/cpu,
which tell
- physical package id
- number of threads
for each CPU.
Using this info, you should be able to detect it. The problem is that they
are not using the same keywords. I'm asking them to make those fields
consistent.
Thanks,
Jun
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Friday, October 25, 2002 11:20 AM
To: Martin J. Bligh
Cc: [email protected]
Subject: Re: How to get number of physical CPU in linux from user space?
On Fri, Oct 25, 2002 at 01:27:00AM -0700, Martin J. Bligh wrote:
> Define "physical CPU number" ;-) If you want to deteact which
I mean the number of cpu chip you can count on the mother board.
> ones are paired up, I believe that if all but the last bit
> of the apicid is the same, they're siblings. You might have to
> dig the apicid out of the bootlog if the cpuinfo stuff doesn't
> tell you.
And you are right. Those apicid, after mask out the siblings,
are put in phys_cpu_id[] array in kernel.
I think about look at bootlog too, but that is not a reliable
way because bootlog might already been flush out after some
time.
Cheers
Chris
On Fri, Oct 25, 2002 at 03:09:09PM -0400, Robert Love wrote:
> +#ifdef CONFIG_SMP
> + 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
Should this be wrapped in a if (cpu_has_ht(c)) { } ?
Seems silly to be displaying HT information on non-HT CPUs.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
On Fri, Oct 25, 2002 at 11:54:53AM -0700, Nakajima, Jun wrote:
> Recent distributions or the AC tree has additional fields in /proc/cpu,
> which tell
> - physical package id
> - number of threads
> for each CPU.
That is exactly what I am looking for.
>
> Using this info, you should be able to detect it. The problem is that they
> are not using the same keywords. I'm asking them to make those fields
> consistent.
Cool. Any idea when will those feature come to stander linux kernel?
Thanks.
Chris
On Fri, 2002-10-25 at 14:54, Nakajima, Jun wrote:
> Recent distributions or the AC tree has additional fields in
> /proc/cpu, which tell
> - physical package id
> - number of threads
Attached patch for 2.5 adds the same fields the 2.4-ac tree have. I
consider those "standard" enough.
Is this something HT users want?
Robert Love
proc.c | 5 +++++
1 files changed, 5 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:06:23.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,10 @@
/* Cache size */
if (c->x86_cache_size >= 0)
seq_printf(m, "cache size\t: %d KB\n", c->x86_cache_size);
+#ifdef CONFIG_SMP
+ 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);
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);
Cool. That will work for me.
Thanks
Chris
On Fri, Oct 25, 2002 at 03:21:28PM -0400, Robert Love wrote:
> 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);
>
On Fri, 2002-10-25 at 20:09, Robert Love wrote:
> +#ifdef CONFIG_SMP
> + 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
Congratulations you just broke glibc. There are reasons the -ac patch
was changed to print something a little different.
> > +#ifdef CONFIG_SMP
> > + 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
>
> Should this be wrapped in a if (cpu_has_ht(c)) { } ?
> Seems silly to be displaying HT information on non-HT CPUs.
Well, without if () you can tell the difference
between 'no hyperthreading' and 'too old
kernel to tell me about hyperthreading so I'd
suggest kill the if ().
Pavel