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: Alan Cox on 8 Nov 2009 15:10 > > Better to be sure that a NOPL whouldn't SIGILL your program, isn't > > it? > > 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. Alan -- 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: Krzysztof Halasa on 8 Nov 2009 15:50 Sven-Haegar Koch <haegar(a)sdinet.de> writes: > But no standard distribution will be made available in a geode special > version - not enough machines in the marekt. So I think it is better to > be able to use the i686 specific things they already support, like > libc6-686 from debian for example. If it's only libc issue (and maybe of a couple of other packages like gzip and bzip2), then I think it would be preferable for distributions to provide a version optimized for Geode, without kernel hacks. Though I guess the above is not actually the case, is it? -- Krzysztof Halasa -- 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 8 Nov 2009 17:20 Keep in mind that if we end up running that on code with any kind of significant fraction of CMOV it will utterly suck. Count 500-odd cycles per emulated instruction. It *is* still useful in some cases - which is why we have x87 emulation already, for example. The question is mostly where the point of diminishing returns go. In theory we could provide a full x86 interpreter (perhaps shared with KVM?) which would allow any instruction at all to be executed. "Alan Cox" <alan(a)lxorguk.ukuu.org.uk> wrote: >> > Better to be sure that a NOPL whouldn't SIGILL your program, isn't >> > it? >> >> 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. > >Alan -- Sent from my mobile phone. Please excuse any lack of formatting.
From: Alan Cox on 8 Nov 2009 19:30 On Sun, 08 Nov 2009 14:10:24 -0800 "H. Peter Anvin" <hpa(a)zytor.com> wrote: > Keep in mind that if we end up running that on code with any kind of significant fraction of CMOV it will utterly suck. cmov is pretty useless anyway and not a good scheduling choice generally speaking on a real CPU - so in fact gcc generates very few of them, but a few is enough to make 686 break on C3 -- 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: Lennart Sorensen on 9 Nov 2009 15:20
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 -- 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/ |