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: Matteo Croce on 9 Nov 2009 16:10 On Mon, Nov 9, 2009 at 9:16 PM, Lennart Sorensen <lsorense(a)csclub.uwaterloo.ca> wrote: > On Sun, Nov 08, 2009 at 07:42:48PM +0100, Matteo Croce wrote: >> There is a small advantage, but considering that GCC isn't much geode aware yet >> there is stil room for improvement IMHO: > > Perhaps gcc considers geode to mean geode GX[m12] not geode LX (which is > newer and the one in question here). > > The Geode GX line prefers i486 code to i586 code (which appears to be > what -march=geode is for). �I am using i486 at the moment when I build > for this one. > > The Geode LX is what is being discussed which is in fact mostly a K6 as > far as I understand things. �It seems to like i686 code, other than > apparently those NOP instructions. �I wonder if the K6 has those noop > instructions and if not, perhaps gcc 4.4's -march=k6-3 would be the > right choice. �I have always suspected the LX was really a K6-3 based > design (the cache sizes are a bit different, but clock speeds and > instruction sets seem to match). > > The Geode NX (which no one has mentioned yet) is an Athlon derived chip. > >> 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 > > -- > Len Sorensen > You're right, indeed this is being discussed here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989 -- 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: H. Peter Anvin on 9 Nov 2009 16:20 On 10/04/2009 07:58 AM, Alan Cox wrote: >> I'm surprised that "i686" in debian depends on the family flag >> in /proc/cpuinfo.. but hey.. weirder things have been done. > > Its compensating for the old gcc bugs where gcc "i686" generated cmov > instructions without any checks whether the CPU supported cmov (which is > optional for a 686 architecture) > > RPM has (or had) similar hacks. Both arguably come about from fundamental > design thinkos in that they treat architecture as "special", not simply > as a set of dependancies (needs x86, x86-cmov, glibc x86-32, ...) as > should hve been done and which would also have made emulators just work > out of the box instead of the current mess. > > Alan Well, for gcc, the string "i686" really means "pentiumpro". All of these are nothing but named feature sets. -hpa -- 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: Willy Tarreau on 10 Nov 2009 00:30 On Sun, Nov 08, 2009 at 08:08:52PM +0000, Alan Cox wrote: > > SIGILL is easier to debug than NOPL mysteriously taking 100x time it > > should, sorry. > > And a working 686 distribution is a great deal more useful to end users, > who outnumber you by a few million to one. It's a very sensible patch, or > perhaps you'd prefer we didn't say. And you forget the user "debug" for > a Geode + i686 without this will be "it hangs when I try and boot the > install CD" > > It would probably also be worth having cmov fixups for the VIA C3 as well. Agreed! I've been using the cmov patch on my kernels for years and it has helped a lot. It isn't *that* slow and allows you to boot a machine which wouldn't boot otherwise. Also, I have memories about the C3 supporting register-to-register CMOV but faulting only on register-to-memory, which is less common and makes the patch even more useful. I'm very happy that people finally consider instruction emulation in kernel. Many other systems do that to help porting code between CPUs, and it's easier to work with that than to have builds for a large variety of CPUs in the same family. I'm sure that many distros would prefer to provide a build optimized for the fastest CPUs around and support the other ones in compatiblity mode than optimize for the smallest ones in order to support everyone. Also, I think that if we start adding emulation, a global and per-task counter would immensely help to know what processes make intensive use of emulation. Willy -- 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: Willy Tarreau on 10 Nov 2009 01:00 On Sun, Nov 08, 2009 at 01:47:59PM -0500, Andres Salomon wrote: > > 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)); > > } > > > Yeah, that looks better. Wouldn't it be even better if we didn't touch boot_cpu_data.x86 in the first place ? We can provide the emulation to support 686 binaries without faking the CPU family/model, I think it would be cleaner. Otherwise we would need to report "real" and "emulated" families in /proc... Willy -- 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: H. Peter Anvin on 10 Nov 2009 01:20
On 11/09/2009 09:27 PM, Willy Tarreau wrote: > > Also, I think that if we start adding emulation, a global and per-task > counter would immensely help to know what processes make intensive use > of emulation. > Agreed. My first question would be if the interpreter in KVM can be reused in any way. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- 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/ |