lkml.org 
[lkml]   [2003]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: 2.6.0-test3-mm1: scheduling while atomic (ext3?)
From
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:47    [W:0.073 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site