Messages in this thread | | | Subject | Re: 2.6.0-test3-mm1: scheduling while atomic (ext3?) | From | Alan Cox <> | Date | 13 Aug 2003 16:20:11 +0100 |
| |
On Mer, 2003-08-13 at 15:20, Andi Kleen wrote: > stuff is basically useless in the kernel because it only helps with data > sets significantly bigger than your cache, and we usually only deal > with 4K chunks of everything.
Could be. I didnt write that code. I think Manfred also played with the copy tricks that came from the AMD slides.
> The K6 has it, right? > Is there a "more original" 3dnow that what has been in the K6?
K6-II/III does. I don't know about original K6. but I believe it doesn't. The original 3Dnow was a joint Cyrix/AMD thing and it lacks several instructions later added (including prefetch). The later Cyrix also has a couple of the additional ones but not prefetch.
> > "Mummy it doesnt work like I personally have decreed it shall lets break > > it and screw all the users". Thats the Dan Bernstein school of charm > > It doesn't work like the AMD instruction reference manual describes it.
Well there is a suprise, AMD didn't design it 8)
> Of course it should be fixed, but the fix as it is a bug workaround > doesn't have to be very fast. So it would be ok to just clear the 3dnow bit. > But then to handle the K6 case (which is interesting, I didn't know) too it > would be probably better to define a separate bit.
What else checks the 3Dnow bit ?
> > We want a pseudobit - otherwise we'll break other code that checks > > 3dnow is present properly. > > Ok. I will do that when I'm back next week unless someone beats me > to it ;-)
Some kind of "has prefetch and its actually useful" 8)
> > If you misalign the instruction you don't seem to get the exception on > > Athlon, dunno about the Opteron errata or if the opteron errata bites in > > 32bit. If it does I guess we should clear mmx, xmm for Opteron by your > > arguments ;) > > I didn't know about the misalignment bit. Interesting. Misalignment to > what boundary?
I'll have to go check again. Its something RH internal testing found when people were going "uh what the hell is going on here" 8)
> But is it slower than an aligned execution? If yes I would prefer my > solution because it keeps the fast path as fast as possible.
Has AMD confirmed that your solution is ok for the K7 as well as K8 - ie that if we hit the errata the fixup recovers the CPU from whatever lunatic state it is now in ?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |