[PATCH] Document Linux's memory barriers
Linus Torvalds
torvalds at osdl.org
Fri Mar 10 04:54:07 EST 2006
On Thu, 9 Mar 2006, David Howells wrote:
>
> I think for the purposes of talking about memory barriers, we consider the
> cache to be part of the memory since the cache coherency mechanisms will give
> the same effect.
Yes and no.
The yes comes from the normal "smp_xxx()" barriers. As far as they are
concerned, the cache coherency means that caches are invisible.
The "no" comes from the IO side. Basically, since IO bypasses caches and
sometimes write buffers, it's simply not ordered wrt normal accesses.
And that's where "bus cycles" actually matter wrt barriers. If you have a
barrier that creates a bus cycle, it suddenly can be ordered wrt IO.
So the fact that x86 SMP ops basically never guarantee any bus cycles
basically means that they are fundamentally no-ops when it comes to IO
serialization. That was really my only point.
> > I think x86 still support the notion of a "locked cycle" on the
> > bus,
>
> I wonder if that's what XCHG and XADD do... There's no particular reason they
> should be that much slower than LOCK INCL/DECL. Of course, I've only measured
> this on my Dual-PPro test box, so other i386 arch CPUs may exhibit other
> behaviour.
I think it's an internal core implementation detail. I don't think they do
anything on the bus, but I suspect that they could easily generate less
optimized uops, simply because they didn't matter as much and didn't fit
the "normal" core uop sequence.
Linus
More information about the Linuxppc64-dev
mailing list