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

[Alan Cox]

On Mer, 2003-08-13 at 13:10, Andi Kleen wrote:
> > Beats me, but then the prefetch code in 2.6 seems broken from
> > 5 seconds of inspection anyway. We are testing the XMM feature
> > and using prefetchnta for Athlon, thats wrong for lots of athlon
> > processors that dont have XMM but do have prefetch/prefetchw,
> > (which btw also seem to work properly on all these processors
> >  while prefetchnta seems to do funky things)
> 
> The early Athlon Specific test was not done to avoid too much bloat.
> (three alternatives instead of two)

Lets replace working code with broken macros whoooo.. progress. Lots of
Athlons don't have XMM, most of the older ones where prefetch has the
most impact in fact. (The XMM using ones have the hw prefetcher too).

> Most Athlons in existence should have XMM already and the rest works.

Lots don't have XMM

> You can hardly call that broken.

I just did. Its worse than 2.4 behaviour.

> That's done for write prefetches correctly.
> (as Intel does not have a write prefetch)

Actually its iffy too. 3Dnow doesnt imply prefetchw. You
must test 3Dnow && vendor==AMD && Athlon. (K6 prefetchw
is slower than not using it, other 3Dnow chips dont have it
eg the Cyrix MII which may explain a couple of things. I don't
see anywhere we mask the 3Dnow property by these but I've not
dug through the CPU code right now to see if we have a "3Dnowplus"
type definition we can check.

I suspect the best way to do prefetch cleanly would be something
like this

#if defined(CONFIG_MK7)
    alternative_input("prefetch" or "prefetchnta")
#else
    alternative_input(ASM_NOP4 or "prefetchnta");
#endif

Ideally we want a 3 way patch table to fix up at boot time but the if
case at least gets us back to desirable situations. Also if I remember
the prefetch exception thing rightly you can misalign the prefetch
instruction as a workaround.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/