Re: [PATCH] Document Linux's memory barriers [try #2]

[Paul Mackerras <paulus@samba.org>]

Ivan Kokshaysky writes:

> On Thu, Mar 09, 2006 at 09:10:49AM +1100, Paul Mackerras wrote:
> > David Howells writes:
> > 
> > > > # define smp_read_barrier_depends()     do { } while(0)
> > > 
> > > What's this one meant to do?
> > 
> > On most CPUs, if you load one value and use the value you get to
> > compute the address for a second load, there is an implicit read
> > barrier between the two loads because of the dependency.  That's not
> > true on alpha, apparently, because of the way their caches are
> > structured.
> 
> Who said?! ;-)

Paul McKenney, after much discussion with Alpha chip designers IIRC.

> > The smp_read_barrier_depends is a read barrier that you
> > use between two loads when there is already a dependency between the
> > loads, and it is a no-op on everything except alpha (IIRC).
> 
> My "Compiler Writer's Guide for the Alpha 21264" says that if the
> result of the first load contributes to the address calculation
> of the second load, then the second load cannot issue until the data
> from the first load is available.

Sure, but because of the partitioned caches on some systems, the
second load can get older data than the first load, even though it
issues later.

If you do:

	CPU 0			CPU 1

	foo = val;
	wmb();
	p = &foo;
				reg = p;
				bar = *reg;

it is apparently possible for CPU 1 to see the new value of p
(i.e. &foo) but an old value of foo (i.e. not val).  This can happen
if p and foo are in different halves of the cache on CPU 1, and there
are a lot of updates coming in for the half containing foo but the
half containing p is quiet.

I added Paul McKenney to the cc list so he can correct anything I have
wrong here.

Paul.
-
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/