It does NOT WORK!
Let the FreBSD people use it, and let them get faster timings. They will
crash, eventually.
The window may be small, but if you do this, then suddenly spinlocks
aren't reliable any more.
The issue is not writes being issued in-order (although all the Intel CPU
books warn you NOT to assume that in-order write behaviour - I bet it
won't be the case in the long run).
The issue is that you _have_ to have a serializing instruction in order to
make sure that the processor doesn't re-order things around the unlock.
For example, with a simple write, the CPU can legally delay a read that
happened inside the critical region (maybe it missed a cache line), and
get a stale value for any of the reads that _should_ have been serialized
by the spinlock.
Note that I actually thought this was a legal optimization, and for a
while I had this in the kernel. It crashed. In random ways.
Note that the fact that it does not crash now is quite possibly because
of either
- we have a lot less contention on our spinlocks these days. That might
hide the problem, because the _spinlock_ will be fine (the cache
coherency still means that the spinlock itself works fine - it's just
that it no longer works reliably as an exclusion thing)
- the window is probably very very small, and you have to be unlucky to
hit it. Faster CPU's, different compilers, whatever.
I might be proven wrong, but I don't think I am.
Note that another thing is that yes, "btcl" may be the worst possible
thing to use for this, and you might test whether a simpler "xor+xchgl"
might be better - it's still serializing because it is locked, but it
should be the normal 12 cycles that Intel always seems to waste on
serializing instructions rather than 22 cycles.
Linus
-
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/