Re: 2.6.0-test3-mm1: scheduling while atomic (ext3?)

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

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  ?