Gérard Roudier wrote:
> My understanding didn't change. There is no publically available erratum
> description that prevents on paper the memory ordering based spin
> unlocking from failing on Pentia ans PPro generation processors. This was
> already true on the previous thread. Even errata #66 and #92 for early
> PPro donnot break it since they just may let a processor read an early
> value and the lock prefixed spinlock will be reentered by the loser CPU
> and fix the problem.
You're referring to documentation. A consensus was reached in the
earlier threads that the documentation says movb is ok although it's not
direct about saying it.
However, it was believed that real processors has an undocumented bug
because of the large number of tests programs flying around, where some
of them failed. So the last thing from Linus was that there appeared to
be an undocumented bug on early PPro steppings.
What's been clarified isn't the documentation, it's the fact that the
test programs that failed weren't relevant to spin-unlocking, though
they are relevant to some other critical things in the kernel. And now
we've got proper test results for all PPro steppings.
Finally, Andy Glew pointed out that although we can use "movb" for
spin-unlock on Pentiums and up, there were 386 and 486 SMP systems where
we cannot, and there might possibly be some Pentium systems where we
cannot too.
> At this point, we must decide if we want to run the risk of jaming our
> finger in all the "small windows" that haven't been discovered yet (or
> are just not documented), or not. :-)
Precisely. The final word is that Intel haven't received reports of
problems due to using "movb" in various other major operating systems.
So it's probably ok :-)
> > Now, we understand that the faster code works with all Intel-style SMP
> > systems from Pentiums up, but may fail for some 386 or 486 SMP systems.
> > And we understand why.
>
> Bloated applications will eat this performance gain in less than half
> the changes of a single update, given the bloating mania that occurs
> nowadays, in my opinion.
You're probably thinking of the broken mm code recently :-)
It's true, Linux does a lot more now and it's not necessarily faster.
There are only a few people doing the real thinking and coding of the
core things like fs and mm, and they appear to be either overworked or
too reluctant to make major changes in this "code freeze" time.
Unfortunately, not all the ideas in there seem to work too well. A lot
of experiments have been tried and good solutions are still some way
off. IMO.
> Indeed this is complex. This happens to be at least as complex and
> sometime more when having from a driver to deal with a PCI device through
> all the variations of bridges that have been invented, and for such
> exercise we donnot have a usable LOCK protocol.
As Alan pointed out, to flush your PCI writes, you have to do a PCI
read.
have a nice day,
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:14 EST