I recently bought a Dual Core AMD Athlon 64 X2 4400+ CPU and dropped a
2.6.15 kernel on the box and it runs very nice, but /proc/cpuinfo
shows a few things that seem slightly odd to me (haven't tried earlier
kernels on this so I don't know if cpuinfo looked different
previously).
It may be that it's absolutely correct and not odd at all, but I
thought I'd just ask :)
Here's what cat /proc/cpuinfo shows :
juhl@dragon:~$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 35
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
stepping : 2
cpu MHz : 2200.260
cache size : 1024 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy
bogomips : 4403.36
processor : 1
vendor_id : AuthenticAMD
cpu family : 15
model : 35
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
stepping : 2
cpu MHz : 2200.260
cache size : 1024 KB
physical id : 127
siblings : 1
core id : 1
cpu cores : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy
bogomips : 4399.53
So, what's odd with that?
Well, first of all you'll notice that the second core shows a
"physical id" of 127 while the first core shows an id of 0. Shouldn't
the second core be id 1, just like the "core id" fields are 0 & 1?
Second thing I find slightly odd is the lack of "sse3" in the "flags" list.
I was under the impression that all AMD Athlon 64 X2 CPU's featured SSE3?
Is it a case of:
a) Me being wrong, not all Athlon 64 X2's feature SSE3?
b) The CPU actually featuring SSE3 but Linux not taking advantage of it?
c) The CPU features SSE3 and it's being utilized, but /proc/cpuinfo
doesn't show that fact?
d) Something else?
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
On Mon, 2006-01-09 at 21:18 +0100, Jesper Juhl wrote:
> Second thing I find slightly odd is the lack of "sse3" in the "flags" list.
> I was under the impression that all AMD Athlon 64 X2 CPU's featured SSE3?
> Is it a case of:
> a) Me being wrong, not all Athlon 64 X2's feature SSE3?
> b) The CPU actually featuring SSE3 but Linux not taking advantage of it?
> c) The CPU features SSE3 and it's being utilized, but /proc/cpuinfo
> doesn't show that fact?
> d) Something else?
Can't help you with the rest, but SSE3 is called "pni" in cpuinfo for
historical reasons, IIRC.
--
Dave Dillow <[email protected]>
Hi,
On Monday, 9 January 2006 21:18, Jesper Juhl wrote:
> I recently bought a Dual Core AMD Athlon 64 X2 4400+ CPU and dropped a
> 2.6.15 kernel on the box and it runs very nice, but /proc/cpuinfo
> shows a few things that seem slightly odd to me (haven't tried earlier
> kernels on this so I don't know if cpuinfo looked different
> previously).
> It may be that it's absolutely correct and not odd at all, but I
> thought I'd just ask :)
>
> Here's what cat /proc/cpuinfo shows :
>
> juhl@dragon:~$ cat /proc/cpuinfo
> processor : 0
> vendor_id : AuthenticAMD
> cpu family : 15
> model : 35
> model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
> stepping : 2
> cpu MHz : 2200.260
> cache size : 1024 KB
> physical id : 0
> siblings : 1
> core id : 0
> cpu cores : 1
> fdiv_bug : no
> hlt_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 1
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
> fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy
> bogomips : 4403.36
>
> processor : 1
> vendor_id : AuthenticAMD
> cpu family : 15
> model : 35
> model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
> stepping : 2
> cpu MHz : 2200.260
> cache size : 1024 KB
> physical id : 127
> siblings : 1
> core id : 1
> cpu cores : 1
> fdiv_bug : no
> hlt_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 1
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
> fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy
> bogomips : 4399.53
>
>
> So, what's odd with that?
>
> Well, first of all you'll notice that the second core shows a
> "physical id" of 127 while the first core shows an id of 0. Shouldn't
> the second core be id 1, just like the "core id" fields are 0 & 1?
FWIW, I'm running 2.6.15 on Athlon X2 4200 and the second core's
physical id is 0 (ie. same as of the frist one), the number of siblings
for each core is 2, and the "cpu cores" value is 2 as well (yours is 1,
apparently ;-)).
Greetings,
Rafael
On Monday 09-January-2006 22:10, Rafael J. Wysocki wrote:
> Hi,
>
> On Monday, 9 January 2006 21:18, Jesper Juhl wrote:
> > I recently bought a Dual Core AMD Athlon 64 X2 4400+ CPU and dropped a
> > 2.6.15 kernel on the box and it runs very nice, but /proc/cpuinfo
> > shows a few things that seem slightly odd to me (haven't tried earlier
> > kernels on this so I don't know if cpuinfo looked different
> > previously).
> > It may be that it's absolutely correct and not odd at all, but I
> > thought I'd just ask :)
> >
> > Here's what cat /proc/cpuinfo shows :
> >
> > juhl@dragon:~$ cat /proc/cpuinfo
> > processor : 0
> > vendor_id : AuthenticAMD
> > cpu family : 15
> > model : 35
> > model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
> > stepping : 2
> > cpu MHz : 2200.260
> > cache size : 1024 KB
> > physical id : 0
> > siblings : 1
> > core id : 0
> > cpu cores : 1
> > fdiv_bug : no
> > hlt_bug : no
> > f00f_bug : no
> > coma_bug : no
> > fpu : yes
> > fpu_exception : yes
> > cpuid level : 1
> > wp : yes
> > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> > mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
> > fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy
> > bogomips : 4403.36
> >
> > processor : 1
> > vendor_id : AuthenticAMD
> > cpu family : 15
> > model : 35
> > model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
> > stepping : 2
> > cpu MHz : 2200.260
> > cache size : 1024 KB
> > physical id : 127
> > siblings : 1
> > core id : 1
> > cpu cores : 1
> > fdiv_bug : no
> > hlt_bug : no
> > f00f_bug : no
> > coma_bug : no
> > fpu : yes
> > fpu_exception : yes
> > cpuid level : 1
> > wp : yes
> > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> > mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
> > fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy
> > bogomips : 4399.53
> >
> >
> > So, what's odd with that?
> >
> > Well, first of all you'll notice that the second core shows a
> > "physical id" of 127 while the first core shows an id of 0. Shouldn't
> > the second core be id 1, just like the "core id" fields are 0 & 1?
>
> FWIW, I'm running 2.6.15 on Athlon X2 4200 and the second core's
> physical id is 0 (ie. same as of the frist one), the number of siblings
> for each core is 2, and the "cpu cores" value is 2 as well (yours is 1,
> apparently ;-)).
Same here. cpu cores is 2.
Random try: Do you have CONFIG_NR_CPUS=2 in your config?
edmondo@balrog ~ $ uname -a
Linux balrog 2.6.15 #1 SMP Tue Jan 3 19:44:52 CET 2006 x86_64
AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ AuthenticAMD GNU/Linux
edmondo@balrog ~ $ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 35
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
stepping : 2
cpu MHz : 1005.170
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy
bogomips : 2012.38
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp
processor : 1
vendor_id : AuthenticAMD
cpu family : 15
model : 35
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
stepping : 2
cpu MHz : 1005.170
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy
bogomips : 2012.38
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp
ciao
edmondo
On 1/9/06, Edmondo Tommasina <[email protected]> wrote:
> On Monday 09-January-2006 22:10, Rafael J. Wysocki wrote:
> > Hi,
> >
>
> Same here. cpu cores is 2.
>
> Random try: Do you have CONFIG_NR_CPUS=2 in your config?
>
Yup.
$ zcat /proc/config.gz | grep NR_CPUS
CONFIG_NR_CPUS=2
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
On 1/9/06, Dave Dillow <[email protected]> wrote:
> On Mon, 2006-01-09 at 21:18 +0100, Jesper Juhl wrote:
> > Second thing I find slightly odd is the lack of "sse3" in the "flags" list.
> > I was under the impression that all AMD Athlon 64 X2 CPU's featured SSE3?
> > Is it a case of:
> > a) Me being wrong, not all Athlon 64 X2's feature SSE3?
> > b) The CPU actually featuring SSE3 but Linux not taking advantage of it?
> > c) The CPU features SSE3 and it's being utilized, but /proc/cpuinfo
> > doesn't show that fact?
> > d) Something else?
>
> Can't help you with the rest, but SSE3 is called "pni" in cpuinfo for
> historical reasons, IIRC.
Ahh yes, PNI as in Prescot New Instructions - right?
Hmm, someone really ought to rename that to sse3 these days.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
On Monday 09-January-2006 23:41, Jesper Juhl wrote:
> On 1/9/06, Edmondo Tommasina <[email protected]> wrote:
> > On Monday 09-January-2006 22:10, Rafael J. Wysocki wrote:
> > > Hi,
> > >
> >
> > Same here. cpu cores is 2.
> >
> > Random try: Do you have CONFIG_NR_CPUS=2 in your config?
> >
> Yup.
>
> $ zcat /proc/config.gz | grep NR_CPUS
> CONFIG_NR_CPUS=2
Ok :-)
Attached my .config. Maybe it's usefull.
ciao
edmondo
Jesper Juhl <[email protected]> writes:
>
> Well, first of all you'll notice that the second core shows a
> "physical id" of 127 while the first core shows an id of 0. Shouldn't
> the second core be id 1, just like the "core id" fields are 0 & 1?
In theory it could be an uninitialized phys_proc_id (0xff >> 1),
but it could be also the BIOS just setting the local APIC of CPU 1
to 0xff for some reason.
If you add a printk("PHYSCPU %d %x\n", smp_processor_id(), phys_proc_id[smp_processor_id()])
at the end of arch/x86_64/kernel/setup.c:early_identify_cpu() what does
dmesg | grep PHYSCPU output?
>
> Second thing I find slightly odd is the lack of "sse3" in the "flags" list.
> I was under the impression that all AMD Athlon 64 X2 CPU's featured SSE3?
> Is it a case of:
> a) Me being wrong, not all Athlon 64 X2's feature SSE3?
> b) The CPU actually featuring SSE3 but Linux not taking advantage of it?
> c) The CPU features SSE3 and it's being utilized, but /proc/cpuinfo
> doesn't show that fact?
> d) Something else?
It's called pni (prescott new instructions) for historical reasons. We added
the bit too early before Intel's marketing department could make up its
mind fully, so Linux is stuck with the old codename.
-Andi
On 10 Jan 2006 02:49:13 +0100, Andi Kleen <[email protected]> wrote:
> Jesper Juhl <[email protected]> writes:
> >
> > Well, first of all you'll notice that the second core shows a
> > "physical id" of 127 while the first core shows an id of 0. Shouldn't
> > the second core be id 1, just like the "core id" fields are 0 & 1?
>
> In theory it could be an uninitialized phys_proc_id (0xff >> 1),
> but it could be also the BIOS just setting the local APIC of CPU 1
> to 0xff for some reason.
>
> If you add a printk("PHYSCPU %d %x\n", smp_processor_id(), phys_proc_id[smp_processor_id()])
> at the end of arch/x86_64/kernel/setup.c:early_identify_cpu() what does
> dmesg | grep PHYSCPU output?
>
Not a thing since I'm using arch/i386 here (32bit distribution
(Slackware), just building a 32bit kernel optimized for K8).
But, I stuck that printk into identify_cpu() in
arch/i386/kernel/cpu/common.c instead, and this is what I get :
$ dmesg | grep PHYSCPU
[ 30.323965] PHYSCPU 0 0
[ 30.402588] PHYSCPU 1 7f
> >
> > Second thing I find slightly odd is the lack of "sse3" in the "flags" list.
> > I was under the impression that all AMD Athlon 64 X2 CPU's featured SSE3?
> > Is it a case of:
> > a) Me being wrong, not all Athlon 64 X2's feature SSE3?
> > b) The CPU actually featuring SSE3 but Linux not taking advantage of it?
> > c) The CPU features SSE3 and it's being utilized, but /proc/cpuinfo
> > doesn't show that fact?
> > d) Something else?
>
> It's called pni (prescott new instructions) for historical reasons. We added
> the bit too early before Intel's marketing department could make up its
> mind fully, so Linux is stuck with the old codename.
>
Does anything actually parse the /proc/cpuinfo flags field? are we
really stuck with it?
Ohh well, no big deal.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
On Tuesday 10 January 2006 03:12, Jesper Juhl wrote:
> On 10 Jan 2006 02:49:13 +0100, Andi Kleen <[email protected]> wrote:
> > Jesper Juhl <[email protected]> writes:
> > >
> > > Well, first of all you'll notice that the second core shows a
> > > "physical id" of 127 while the first core shows an id of 0. Shouldn't
> > > the second core be id 1, just like the "core id" fields are 0 & 1?
> >
> > In theory it could be an uninitialized phys_proc_id (0xff >> 1),
> > but it could be also the BIOS just setting the local APIC of CPU 1
> > to 0xff for some reason.
> >
> > If you add a printk("PHYSCPU %d %x\n", smp_processor_id(), phys_proc_id[smp_processor_id()])
> > at the end of arch/x86_64/kernel/setup.c:early_identify_cpu() what does
> > dmesg | grep PHYSCPU output?
> >
> Not a thing since I'm using arch/i386 here (32bit distribution
> (Slackware), just building a 32bit kernel optimized for K8).
Ah - how legacy.
> But, I stuck that printk into identify_cpu() in
> arch/i386/kernel/cpu/common.c instead, and this is what I get :
> $ dmesg | grep PHYSCPU
> [ 30.323965] PHYSCPU 0 0
> [ 30.402588] PHYSCPU 1 7f
Hmm it looks like the phys_proc_id initialization is at the wrong
place in 32bit. early_cpu_detect is only called on the BP, not
on the AP. early_intel_workaround is also there incorrectly.
Might be a mismerge - it should be one function below.
The appended patch should help, but it's untested.
>
> > >
> > > Second thing I find slightly odd is the lack of "sse3" in the "flags" list.
> > > I was under the impression that all AMD Athlon 64 X2 CPU's featured SSE3?
> > > Is it a case of:
> > > a) Me being wrong, not all Athlon 64 X2's feature SSE3?
> > > b) The CPU actually featuring SSE3 but Linux not taking advantage of it?
> > > c) The CPU features SSE3 and it's being utilized, but /proc/cpuinfo
> > > doesn't show that fact?
> > > d) Something else?
> >
> > It's called pni (prescott new instructions) for historical reasons. We added
> > the bit too early before Intel's marketing department could make up its
> > mind fully, so Linux is stuck with the old codename.
> >
> Does anything actually parse the /proc/cpuinfo flags field? are we
> really stuck with it?
Do you really want to find out by a report from a rightfully annoyed user?
I considered at some point to print sse3 in addition to pni, but then
it seemed like too much bloat for only a cosmetical issue. Maybe if it
becomes a popular FAQ, but it isn't that far yet.
(I can just see the headlines for such a patch -
"Linux 2.6.20 finally adding SSE3 support")
-Andi
i386: Move phys_proc_id/early intel workaround to correct function.
early_cpu_detect only runs on the BP, but this code needs to run
on all CPUs.
Looks like a mismerge somewhere. Also add a warning comment.
Signed-off-by: Andi Kleen <[email protected]>
Index: linux/arch/i386/kernel/cpu/common.c
===================================================================
--- linux.orig/arch/i386/kernel/cpu/common.c
+++ linux/arch/i386/kernel/cpu/common.c
@@ -204,7 +204,10 @@ static int __devinit have_cpuid_p(void)
/* Do minimum CPU detection early.
Fields really needed: vendor, cpuid_level, family, model, mask, cache alignment.
- The others are not touched to avoid unwanted side effects. */
+ The others are not touched to avoid unwanted side effects.
+
+ WARNING: this function is only called on the BP. Don't add code here
+ that is supposed to run on all CPUs. */
static void __init early_cpu_detect(void)
{
struct cpuinfo_x86 *c = &boot_cpu_data;
@@ -236,12 +239,6 @@ static void __init early_cpu_detect(void
if (cap0 & (1<<19))
c->x86_cache_alignment = ((misc >> 8) & 0xff) * 8;
}
-
- early_intel_workaround(c);
-
-#ifdef CONFIG_X86_HT
- phys_proc_id[smp_processor_id()] = (cpuid_ebx(1) >> 24) & 0xff;
-#endif
}
void __devinit generic_identify(struct cpuinfo_x86 * c)
@@ -289,6 +286,12 @@ void __devinit generic_identify(struct c
get_model_name(c); /* Default name */
}
}
+
+ early_intel_workaround(c);
+
+#ifdef CONFIG_X86_HT
+ phys_proc_id[smp_processor_id()] = (cpuid_ebx(1) >> 24) & 0xff;
+#endif
}
static void __devinit squash_the_stupid_serial_number(struct cpuinfo_x86 *c)
On 1/10/06, Andi Kleen <[email protected]> wrote:
> On Tuesday 10 January 2006 03:12, Jesper Juhl wrote:
> > On 10 Jan 2006 02:49:13 +0100, Andi Kleen <[email protected]> wrote:
> > > Jesper Juhl <[email protected]> writes:
> > > >
> > > > Well, first of all you'll notice that the second core shows a
> > > > "physical id" of 127 while the first core shows an id of 0. Shouldn't
> > > > the second core be id 1, just like the "core id" fields are 0 & 1?
> > >
> > > In theory it could be an uninitialized phys_proc_id (0xff >> 1),
> > > but it could be also the BIOS just setting the local APIC of CPU 1
> > > to 0xff for some reason.
> > >
> > > If you add a printk("PHYSCPU %d %x\n", smp_processor_id(), phys_proc_id[smp_processor_id()])
> > > at the end of arch/x86_64/kernel/setup.c:early_identify_cpu() what does
> > > dmesg | grep PHYSCPU output?
> > >
> > Not a thing since I'm using arch/i386 here (32bit distribution
> > (Slackware), just building a 32bit kernel optimized for K8).
>
> Ah - how legacy.
>
Yeah, but since my distro of choice is 32bit only and I don't much
feel like porting it myself or using an unofficial port (slamd64) I'm
sticking with a 32bit userspace. And as long as userspace is pure
32bit there doesn't seem to be much point in building a 64bit kernel.
And I only have 2GB of RAM, so I don't have a use for the larger 64bit
address space.
I also don't run any apps that do a lot of math on >32bit numbers, so
there's not much gain there either.
I guess I would bennefit from the extra GPR's, but then I would at the
same time loose a bit by all pointers being 64bit - both lose some
disk space due to larger binaries and I'd have increased memory use
and less efficient L1/L2 cache use.
I don't think there would actually be much gain for me in switching to
a 64bit kernel with a 64bit userspace atm.
But if I'm wrong I'd of course love to hear about it :)
> > But, I stuck that printk into identify_cpu() in
> > arch/i386/kernel/cpu/common.c instead, and this is what I get :
> > $ dmesg | grep PHYSCPU
> > [ 30.323965] PHYSCPU 0 0
> > [ 30.402588] PHYSCPU 1 7f
>
> Hmm it looks like the phys_proc_id initialization is at the wrong
> place in 32bit. early_cpu_detect is only called on the BP, not
> on the AP. early_intel_workaround is also there incorrectly.
> Might be a mismerge - it should be one function below.
>
> The appended patch should help, but it's untested.
>
It does help. Thank you Andi.
Guess this should be merged.
$ dmesg | grep PHYSCPU
[ 34.202835] PHYSCPU 0 0
[ 34.281459] PHYSCPU 1 0
$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 35
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
stepping : 2
cpu MHz : 2200.150
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
lm 3dnowext 3dnow pni lahf_lm cmp_legacy ts fid vid ttp
bogomips : 4401.86
processor : 1
vendor_id : AuthenticAMD
cpu family : 15
model : 35
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
stepping : 2
cpu MHz : 2200.150
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
lm 3dnowext 3dnow pni lahf_lm cmp_legacy ts fid vid ttp
bogomips : 4399.53
> >
> > > >
> > > > Second thing I find slightly odd is the lack of "sse3" in the "flags" list.
> > > > I was under the impression that all AMD Athlon 64 X2 CPU's featured SSE3?
> > > > Is it a case of:
> > > > a) Me being wrong, not all Athlon 64 X2's feature SSE3?
> > > > b) The CPU actually featuring SSE3 but Linux not taking advantage of it?
> > > > c) The CPU features SSE3 and it's being utilized, but /proc/cpuinfo
> > > > doesn't show that fact?
> > > > d) Something else?
> > >
> > > It's called pni (prescott new instructions) for historical reasons. We added
> > > the bit too early before Intel's marketing department could make up its
> > > mind fully, so Linux is stuck with the old codename.
> > >
> > Does anything actually parse the /proc/cpuinfo flags field? are we
> > really stuck with it?
>
> Do you really want to find out by a report from a rightfully annoyed user?
No, not really. Guess you are right, it could potentially break
userspace to change it now - better not to.
> I considered at some point to print sse3 in addition to pni, but then
> it seemed like too much bloat for only a cosmetical issue. Maybe if it
> becomes a popular FAQ, but it isn't that far yet.
>
Right, it's fine as 'pni' for now.
> (I can just see the headlines for such a patch -
> "Linux 2.6.20 finally adding SSE3 support")
>
Hehe.
> -Andi
>
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
Jesper Juhl wrote:
>On 1/10/06, Andi Kleen <[email protected]> wrote:
>
>
>>On Tuesday 10 January 2006 03:12, Jesper Juhl wrote:
>>
>>
...
>>Ah - how legacy.
>>
>>
>>
>Yeah, but since my distro of choice is 32bit only and I don't much
>feel like porting it myself or using an unofficial port (slamd64) I'm
>sticking with a 32bit userspace. And as long as userspace is pure
>32bit there doesn't seem to be much point in building a 64bit kernel.
>And I only have 2GB of RAM, so I don't have a use for the larger 64bit
>address space.
>I also don't run any apps that do a lot of math on >32bit numbers, so
>there's not much gain there either.
>I guess I would bennefit from the extra GPR's, but then I would at the
>same time loose a bit by all pointers being 64bit - both lose some
>disk space due to larger binaries and I'd have increased memory use
>and less efficient L1/L2 cache use.
>
>I don't think there would actually be much gain for me in switching to
>a 64bit kernel with a 64bit userspace atm.
>But if I'm wrong I'd of course love to hear about it :)
>
>
>
Has anyone done any actual benchmark tests that show 64-bit vs 32-bit
environments/distributions with Athlon64 processors. If so, I love to
see the results. I too elected to stick with 32-bit, using the same
reasoning/guessing above.
--
Jeffrey Hundstad
On Tue, 10 Jan 2006, Jeffrey Hundstad wrote:
>
>> On 1/10/06, Andi Kleen <[email protected]> wrote:
>>
>>> On Tuesday 10 January 2006 03:12, Jesper Juhl wrote:
>>>
> ...
>
>>> Ah - how legacy.
>>>
>>>
>> Yeah, but since my distro of choice is 32bit only and I don't much
>> feel like porting it myself or using an unofficial port (slamd64) I'm
>> sticking with a 32bit userspace. And as long as userspace is pure
>> 32bit there doesn't seem to be much point in building a 64bit kernel.
>> And I only have 2GB of RAM, so I don't have a use for the larger 64bit
>> address space.
>> I also don't run any apps that do a lot of math on >32bit numbers, so
>> there's not much gain there either.
>> I guess I would bennefit from the extra GPR's, but then I would at the
>> same time loose a bit by all pointers being 64bit - both lose some
>> disk space due to larger binaries and I'd have increased memory use
>> and less efficient L1/L2 cache use.
>>
>> I don't think there would actually be much gain for me in switching to
>> a 64bit kernel with a 64bit userspace atm.
>> But if I'm wrong I'd of course love to hear about it :)
>>
>>
>
> Has anyone done any actual benchmark tests that show 64-bit vs 32-bit
> environments/distributions with Athlon64 processors. If so, I love to see
> the results. I too elected to stick with 32-bit, using the same
> reasoning/guessing above.
remember that benchmarks are all dependant on your workload, but on some
of my workloads (lots of fork-based network services) I've seen a 50%+
increase by switching from a 32 bit to 64 bit kernel with 32 bit
userspace, and a further 50%+ increase by switching to a 64 bit userspace.
remember that on amd64 systems 64 bit programs have access to twice as
many registers as 32 bit programs. This can be more of a win then the
extra pointer size is a loss.
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
David Lang wrote:
> On Tue, 10 Jan 2006, Jeffrey Hundstad wrote:
>
>>
>>> On 1/10/06, Andi Kleen <[email protected]> wrote:
>>>
>>>> On Tuesday 10 January 2006 03:12, Jesper Juhl wrote:
>>>>
>> ...
>>
>>>> Ah - how legacy.
>>>>
>>>>
>>> Yeah, but since my distro of choice is 32bit only and I don't much
>>> feel like porting it myself or using an unofficial port (slamd64) I'm
>>> sticking with a 32bit userspace. And as long as userspace is pure
>>> 32bit there doesn't seem to be much point in building a 64bit kernel.
>>> And I only have 2GB of RAM, so I don't have a use for the larger 64bit
>>> address space.
>>> I also don't run any apps that do a lot of math on >32bit numbers, so
>>> there's not much gain there either.
>>> I guess I would bennefit from the extra GPR's, but then I would at the
>>> same time loose a bit by all pointers being 64bit - both lose some
>>> disk space due to larger binaries and I'd have increased memory use
>>> and less efficient L1/L2 cache use.
>>>
>>> I don't think there would actually be much gain for me in switching to
>>> a 64bit kernel with a 64bit userspace atm.
>>> But if I'm wrong I'd of course love to hear about it :)
>>>
>>>
>>
>> Has anyone done any actual benchmark tests that show 64-bit vs 32-bit
>> environments/distributions with Athlon64 processors. If so, I love
>> to see the results. I too elected to stick with 32-bit, using the
>> same reasoning/guessing above.
>
>
> remember that benchmarks are all dependant on your workload, but on
> some of my workloads (lots of fork-based network services) I've seen a
> 50%+ increase by switching from a 32 bit to 64 bit kernel with 32 bit
> userspace, and a further 50%+ increase by switching to a 64 bit
> userspace.
>
Thanks for your response. I'm prob. being stupid here... but does
"increase" here mean faster or slower?
> remember that on amd64 systems 64 bit programs have access to twice as
> many registers as 32 bit programs. This can be more of a win then the
> extra pointer size is a loss.
If you've done other "standard" type of benchmarks between the two
please post your results. Also, is there a big hit by using a nearly
pure 32-bit environment + the rare 64-bit program when needed?
--
Jeffrey Hundstad
On Tue, 10 Jan 2006, Jeffrey Hundstad wrote:
> Date: Tue, 10 Jan 2006 14:50:05 -0600
> David Lang wrote:
>
>> On Tue, 10 Jan 2006, Jeffrey Hundstad wrote:
>>
>>>
>>>> On 1/10/06, Andi Kleen <[email protected]> wrote:
>>>>
>>>>> On Tuesday 10 January 2006 03:12, Jesper Juhl wrote:
>>>>>
>>> ...
>>>
>>>>> Ah - how legacy.
>>>>>
>>>>>
>>>> Yeah, but since my distro of choice is 32bit only and I don't much
>>>> feel like porting it myself or using an unofficial port (slamd64) I'm
>>>> sticking with a 32bit userspace. And as long as userspace is pure
>>>> 32bit there doesn't seem to be much point in building a 64bit kernel.
>>>> And I only have 2GB of RAM, so I don't have a use for the larger 64bit
>>>> address space.
>>>> I also don't run any apps that do a lot of math on >32bit numbers, so
>>>> there's not much gain there either.
>>>> I guess I would bennefit from the extra GPR's, but then I would at the
>>>> same time loose a bit by all pointers being 64bit - both lose some
>>>> disk space due to larger binaries and I'd have increased memory use
>>>> and less efficient L1/L2 cache use.
>>>>
>>>> I don't think there would actually be much gain for me in switching to
>>>> a 64bit kernel with a 64bit userspace atm.
>>>> But if I'm wrong I'd of course love to hear about it :)
>>>>
>>>>
>>>
>>> Has anyone done any actual benchmark tests that show 64-bit vs 32-bit
>>> environments/distributions with Athlon64 processors. If so, I love to see
>>> the results. I too elected to stick with 32-bit, using the same
>>> reasoning/guessing above.
>>
>>
>> remember that benchmarks are all dependant on your workload, but on some of
>> my workloads (lots of fork-based network services) I've seen a 50%+
>> increase by switching from a 32 bit to 64 bit kernel with 32 bit userspace,
>> and a further 50%+ increase by switching to a 64 bit userspace.
>>
>
> Thanks for your response. I'm prob. being stupid here... but does "increase"
> here mean faster or slower?
increase means faster.
>> remember that on amd64 systems 64 bit programs have access to twice as many
>> registers as 32 bit programs. This can be more of a win then the extra
>> pointer size is a loss.
>
>
> If you've done other "standard" type of benchmarks between the two please
> post your results. Also, is there a big hit by using a nearly pure 32-bit
> environment + the rare 64-bit program when needed?
I haven't done other benchmarks myself, but I have seen some database
benchmarks (MySQL and Postgres) on the net that showed a doubling of the
database performance when going from pure 32 bit to pure 64 bit.
I don't see any reason why there would be a direct performance penalty in
a mixed environment (other then the fact that you may end up eating up
some ram by having 32bit and 64 bit shared libraries loaded at the same
time)
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
> Has anyone done any actual benchmark tests that show 64-bit vs 32-bit
> environments/distributions with Athlon64 processors. If so, I love to
> see the results. I too elected to stick with 32-bit, using the same
> reasoning/guessing above.
This discussion is totally off topic on this mailing list. Please stop
it right now. And if not please take me out of cc.
-Andi
On Tue, 10 Jan 2006, Jeffrey Hundstad wrote:
>
> Has anyone done any actual benchmark tests that show 64-bit vs 32-bit
> environments/distributions with Athlon64 processors. If so, I love to see
> the results. I too elected to stick with 32-bit, using the same
> reasoning/guessing above.
>
Some months ago, on a 2GHz San Diego (4000+) I ran some tests using
linuxfromscratch with 2.6.11.11, 1 GB PC3200, ext3, 5 runs of each
(a) specific oggenc and photo manipulations in parallel
64-bit kernel, total time 246.053 to 257.601 sec, avg 250.022, std dev
4.62415
32-bit kernel, total time 247.572 to 258.963 sec, avg 252.405, std dev
4.22909
pure64, total time 172.942 to 177.532 sec, avg 174.582, std dev
1.90047
At that time, I hadn't built multilib.
Ken
--
das eine Mal als Trag?die, das andere Mal als Farce
In-Reply-To: <[email protected]>
On Tue, 10 Jan 2006, Jesper Juhl wrote:
> Yeah, but since my distro of choice is 32bit only and I don't much
> feel like porting it myself or using an unofficial port (slamd64) I'm
> sticking with a 32bit userspace. And as long as userspace is pure
> 32bit there doesn't seem to be much point in building a 64bit kernel.
Of course there's a point -- you can test both x86-64 and i386 kernels.
Sometimes one has a bug the other doesn't, as you just found.
FWIW, 32-bit userspace works almost perfectly for me on 64-bit kernel
(everything but iptables and old pcmcia-cs package.)
--
Chuck
Currently reading: _Olympos_ by Dan Simmons
Did the patch that fixes the out of sync cpufreq messages make it into
2.6.15 stable series? I just acquired an athlon 64 x2 system, and was
having this:
Feb 12 15:33:33 [kernel] powernow-k8: error - out of sync, fix 0xa 0x2,
vid 0xa 0xa
Feb 12 15:33:59 [kernel] init_special_inode: bogus i_mode (300)
Feb 12 15:33:59 [kernel] ReiserFS: hda8: warning: vs-13075:
reiserfs_read_locked_inode: dead inode read from disk [283239 150550 0x0
SD]. This is likely to be race with knfsd. Ignore
Some filesystem corruptions have occurred as a result. I'm testing
2.6.16-rc2 under the exact same conditions currently, and so far, no
errors.
Thanks,
Brandon Low
On Tue, 01/10/06 at 02:49:13 +0100, Andi Kleen wrote:
> Jesper Juhl <[email protected]> writes:
> >
> > Well, first of all you'll notice that the second core shows a
> > "physical id" of 127 while the first core shows an id of 0. Shouldn't
> > the second core be id 1, just like the "core id" fields are 0 & 1?
>
> In theory it could be an uninitialized phys_proc_id (0xff >> 1),
> but it could be also the BIOS just setting the local APIC of CPU 1
> to 0xff for some reason.
>
> If you add a printk("PHYSCPU %d %x\n", smp_processor_id(), phys_proc_id[smp_processor_id()])
> at the end of arch/x86_64/kernel/setup.c:early_identify_cpu() what does
> dmesg | grep PHYSCPU output?
>
> >
> > Second thing I find slightly odd is the lack of "sse3" in the "flags" list.
> > I was under the impression that all AMD Athlon 64 X2 CPU's featured SSE3?
> > Is it a case of:
> > a) Me being wrong, not all Athlon 64 X2's feature SSE3?
> > b) The CPU actually featuring SSE3 but Linux not taking advantage of it?
> > c) The CPU features SSE3 and it's being utilized, but /proc/cpuinfo
> > doesn't show that fact?
> > d) Something else?
>
> It's called pni (prescott new instructions) for historical reasons. We added
> the bit too early before Intel's marketing department could make up its
> mind fully, so Linux is stuck with the old codename.
>
> -Andi
> -
> 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 Monday 13 February 2006 02:53, Brandon Low wrote:
> Did the patch that fixes the out of sync cpufreq messages make it into
> 2.6.15 stable series? I just acquired an athlon 64 x2 system, and was
> having this:
My issues with cpufreq were resolved in 2.6.16-rc2, I highly recommend that
you try it, or Linus's recently pushed -rc3.
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
On Monday 13 February 2006 03:53, Brandon Low wrote:
> Did the patch that fixes the out of sync cpufreq messages make it into
> 2.6.15 stable series? I just acquired an athlon 64 x2 system, and was
> having this:
No it didn't. But thanks for the reminder - i will submit it right now.
-Andi