i686 quirk for AMD Geode
in [Kernel]
|
Prev: [PATCH 1/1] PM: Thaws refrigerated and to be exited kernel threads
Next: drm/ksm -> s2disk -> resume -> [drm:r100_ring_test] *ERROR* radeon: ring test failed (sracth(0x15E4)=0xCAFEDEAD)
From: Pavel Machek on 8 Nov 2009 13:20 On Sun 2009-11-08 18:40:06, Matteo Croce wrote: > On Sun, Nov 8, 2009 at 6:37 PM, Pavel Machek <pavel(a)ucw.cz> wrote: > > On Fri 2009-11-06 23:18:06, Matteo Croce wrote: > >> On Fri, Nov 6, 2009 at 5:44 PM, H. Peter Anvin <hpa(a)zytor.com> wrote: > >> > On 11/06/2009 06:59 AM, Matteo Croce wrote: > >> >> indeed it has MMX, MMXEXT and CMOV, just lacks the long NOP instruction (NOPL). > >> > > >> > MMX and MMXEXT are hardly hallmarks of i686, which leaves only cmov. > >> > I'm somewhat wondering about the general value of this patch; is i686 > >> > code really that much faster on Geode that it's worth it? > >> > > >> > ? ? ? ?-hpa > >> > > >> > -- > >> > H. Peter Anvin, Intel Open Source Technology Center > >> > I work for Intel. ?I don't speak on their behalf. > >> > > >> > > >> > >> yes, I did some test like gzip, bzip2, lame etc and they give more or less > >> the same results of dhrystone > >> > >> root(a)alix:/usr/src# CFLAGS='-march=i586' ./dry.c > >> Microseconds for one run through Dhrystone: � � � �1.4 > >> Dhrystones per Second: � � � � � � � � � � � � �740741 > > ... > >> root(a)alix:/usr/src# CFLAGS='-march=i686' ./dry.c > >> Trying 5000000 runs through Dhrystone: > >> Microseconds for one run through Dhrystone: � � � �1.2 > >> Dhrystones per Second: � � � � � � � � � � � � �841751 > > > > Teach gcc that geodelx exists? No need to break kernel for that... and > > you probably can gain even bigger gains. > > Gcc 4.4 already knows about it, just sucks at optimizing: Good. So there's really no point in breaking kernel. > # CFLAGS='-march=geode' ./dry.c > gcc -c -O3 -march=geode ./dry.c -o dry1.o > gcc -DPASS2 -O3 -march=geode ./dry.c dry1.o -o dry2 > > Dhrystone Benchmark, Version C, Version 2.2 > Program compiled without 'register' attribute > Using times(), HZ=100 > > Trying 5000000 runs through Dhrystone: > Microseconds for one run through Dhrystone: 1.4 > Dhrystones per Second: 719424 ....fix gcc to genereta code at least as good as for i686 and you are done...? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matteo Croce on 8 Nov 2009 13:20 On Sun, Nov 8, 2009 at 7:10 PM, Pavel Machek <pavel(a)ucw.cz> wrote: > On Sun 2009-11-08 18:40:06, Matteo Croce wrote: >> On Sun, Nov 8, 2009 at 6:37 PM, Pavel Machek <pavel(a)ucw.cz> wrote: >> > On Fri 2009-11-06 23:18:06, Matteo Croce wrote: >> >> On Fri, Nov 6, 2009 at 5:44 PM, H. Peter Anvin <hpa(a)zytor.com> wrote: >> >> > On 11/06/2009 06:59 AM, Matteo Croce wrote: >> >> >> indeed it has MMX, MMXEXT and CMOV, just lacks the long NOP instruction (NOPL). >> >> > >> >> > MMX and MMXEXT are hardly hallmarks of i686, which leaves only cmov. >> >> > I'm somewhat wondering about the general value of this patch; is i686 >> >> > code really that much faster on Geode that it's worth it? >> >> > >> >> > ? ? ? ?-hpa >> >> > >> >> > -- >> >> > H. Peter Anvin, Intel Open Source Technology Center >> >> > I work for Intel. ?I don't speak on their behalf. >> >> > >> >> > >> >> >> >> yes, I did some test like gzip, bzip2, lame etc and they give more or less >> >> the same results of dhrystone >> >> >> >> root(a)alix:/usr/src# CFLAGS='-march=i586' ./dry.c >> >> Microseconds for one run through Dhrystone: � � � �1.4 >> >> Dhrystones per Second: � � � � � � � � � � � � �740741 >> > ... >> >> root(a)alix:/usr/src# CFLAGS='-march=i686' ./dry.c >> >> Trying 5000000 runs through Dhrystone: >> >> Microseconds for one run through Dhrystone: � � � �1.2 >> >> Dhrystones per Second: � � � � � � � � � � � � �841751 >> > >> > Teach gcc that geodelx exists? No need to break kernel for that... and >> > you probably can gain even bigger gains. >> >> Gcc 4.4 already knows about it, just sucks at optimizing: > > Good. So there's really no point in breaking kernel. > >> # CFLAGS='-march=geode' ./dry.c >> gcc -c -O3 -march=geode ./dry.c -o dry1.o >> gcc -DPASS2 -O3 -march=geode ./dry.c dry1.o �-o dry2 >> >> Dhrystone Benchmark, Version C, Version 2.2 >> Program compiled without 'register' attribute >> Using times(), HZ=100 >> >> Trying 5000000 runs through Dhrystone: >> Microseconds for one run through Dhrystone: � � � �1.4 >> Dhrystones per Second: � � � � � � � � � � � � �719424 > > ...fix gcc to genereta code at least as good as for i686 and you are > done...? > > � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > This is on my TODO list, but better to discuss it in the GCC mailing list, the kernel should use -march=geode and GCC should generate the best code for the AMD Geode, actually the i686 one -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matteo Croce on 8 Nov 2009 13:30 On Sun, Nov 8, 2009 at 5:05 PM, Andres Salomon <dilinger(a)collabora.co.uk> wrote: > See comment below. �BTW, how does this affect performance on LXs? > Do you have any hard numbers for common tasks? > > On Sat, 7 Nov 2009 12:11:55 +0100 > Matteo Croce <technoboy85(a)gmail.com> wrote: > [...] >> >> --- a/arch/x86/kernel/Makefile � � � �2009-11-06 15:06:52.246223989 >> +0100 +++ b/arch/x86/kernel/Makefile �2009-11-06 >> 15:07:04.294054613 +0100 @@ -89,7 +89,7 @@ >> �obj-$(CONFIG_HPET_TIMER) � � += hpet.o >> >> �obj-$(CONFIG_K8_NB) � � � � �+= k8.o >> -obj-$(CONFIG_MGEODE_LX) � � � � � � �+= geode_32.o mfgpt_32.o >> +obj-$(CONFIG_MGEODE_LX) � � � � � � �+= geode_32.o mfgpt_32.o >> nopl_emu.o obj-$(CONFIG_DEBUG_RODATA_TEST) � �+= test_rodata.o >> �obj-$(CONFIG_DEBUG_NX_TEST) �+= test_nx.o >> >> --- a/arch/x86/kernel/cpu/amd.c � � � 2009-11-06 15:06:52.254223805 >> +0100 +++ b/arch/x86/kernel/cpu/amd.c 2009-11-06 >> 15:07:04.294054613 +0100 @@ -138,8 +138,10 @@ >> � � � } >> >> � � � if (c->x86_model == 10) { >> - � � � � � � /* AMD Geode LX is model 10 */ >> - � � � � � � /* placeholder for any needed mods */ >> + � � � � � � /* Geode only lacks the NOPL instruction to be i686, >> + � � � � � � � �but we can emulate it in the exception handler >> + � � � � � � � �and promote it to a class 6 cpu */ >> + � � � � � � boot_cpu_data.x86 = 6; >> � � � � � � � return; >> � � � } > > If you're going to update this, you also need to make sure that you're > not breaking things that check it. �For example, > arch/x86/include/asm/geode.h has an is_geode_lx check that expects > boot_cpu_data.x86 to be 5. �Please be sure to update all these places > when creating a patch like this. > Right, but what if is_geode_lx() is called befor the x86.id change takes effect? Maybe something like this? --- a/arch/x86/include/asm/geode.h 2009-11-08 19:13:43.531117343 +0100 +++ b/arch/x86/include/asm/geode.h 2009-11-08 19:19:42.130618023 +0100 @@ -177,7 +177,7 @@ static inline int is_geode_lx(void) { return ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) && - (boot_cpu_data.x86 == 5) && + (boot_cpu_data.x86 == 5 || boot_cpu_data.x86 == 6) && (boot_cpu_data.x86_model == 10)); } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matteo Croce on 8 Nov 2009 13:50 On Fri, Nov 6, 2009 at 5:44 PM, H. Peter Anvin <hpa(a)zytor.com> wrote: > On 11/06/2009 06:59 AM, Matteo Croce wrote: >> indeed it has MMX, MMXEXT and CMOV, just lacks the long NOP instruction (NOPL). > > MMX and MMXEXT are hardly hallmarks of i686, which leaves only cmov. > I'm somewhat wondering about the general value of this patch; is i686 > code really that much faster on Geode that it's worth it? > > � � � �-hpa > > -- > H. Peter Anvin, Intel Open Source Technology Center > I work for Intel. �I don't speak on their behalf. > > There is a small advantage, but considering that GCC isn't much geode aware yet there is stil room for improvement IMHO: root(a)alix:/usr/src/dist# ll totale 257M -rwxr-xr-x 1 1000 src 93K 8 nov 2009 bzip2-i586 -rwxr-xr-x 1 1000 src 93K 8 nov 2009 bzip2-i686 -rwxr-xr-x 1 1000 src 60K 8 nov 2009 gzip-i586 -rwxr-xr-x 1 1000 src 60K 8 nov 2009 gzip-i686 -rw-r--r-- 1 1000 src 256M 8 nov 2009 linux-2.6.31.5.tar -rwxr-xr-x 1 1000 src 90K 8 nov 2009 lzma-i586 -rwxr-xr-x 1 1000 src 94K 8 nov 2009 lzma-i686 root(a)alix:/usr/src/dist# time cat linux-2.6.31.5.tar >/dev/null real 0m10.168s user 0m0.030s sys 0m1.390s root(a)alix:/usr/src/dist# time ./gzip-i586 -9 < linux-2.6.31.5.tar >/dev/null real 5m22.331s user 5m10.820s sys 0m11.170s root(a)alix:/usr/src/dist# time ./gzip-i686 -9 < linux-2.6.31.5.tar >/dev/null real 5m3.737s user 4m51.880s sys 0m11.510s root(a)alix:/usr/src/dist# time ./bzip2-i586 -9 < linux-2.6.31.5.tar >/dev/null real 9m16.539s user 9m4.410s sys 0m11.760s root(a)alix:/usr/src/dist# time ./bzip2-i686 -9 < linux-2.6.31.5.tar >/dev/null real 8m48.682s user 8m34.950s sys 0m13.260s -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andres Salomon on 8 Nov 2009 13:50
On Sun, 8 Nov 2009 19:04:35 +0100 Matteo Croce <technoboy85(a)gmail.com> wrote: [...] > > True, but also remove the duplicate function is_geode in the NAND > driver and use the identical one defined in geode.h: > > --- a/drivers/mtd/nand/cs553x_nand.c 2009-11-08 > 18:58:14.835043214 +0100 +++ b/drivers/mtd/nand/cs553x_nand.c > 2009-11-08 19:00:07.914117831 +0100 @@ -30,6 +30,7 @@ > > #include <asm/msr.h> > #include <asm/io.h> > +#include <asm/geode.h> > > #define NR_CS553X_CONTROLLERS 4 > > @@ -260,23 +261,6 @@ > return err; > } > > -static int is_geode(void) > -{ > - /* These are the CPUs which will have a CS553[56] companion > chip */ > - if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD && > - boot_cpu_data.x86 == 5 && > - boot_cpu_data.x86_model == 10) > - return 1; /* Geode LX */ > - > - if ((boot_cpu_data.x86_vendor == X86_VENDOR_NSC || > - boot_cpu_data.x86_vendor == X86_VENDOR_CYRIX) && > - boot_cpu_data.x86 == 5 && > - boot_cpu_data.x86_model == 5) > - return 1; /* Geode GX (née GX2) */ > - > - return 0; > -} > - > > #ifdef CONFIG_MTD_PARTITIONS > static const char *part_probes[] = { "cmdlinepart", NULL }; I think the nand driver needs a bit more love than this. The cs553x is available for non-geode platforms, so a cs553x driver should not be checking for the existence of a specific CPU. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |