>[..] I don't see anything that
>suggests a write on CPU 1 throws out a speculative read result on CPU 2.
In one of Erich's email you'll see exactly that.
I quote him:
---------------------------------------------------------------------
On Wed, 24 Nov 1999, Erich Boleyn wrote:
>
>Date: Wed, 24 Nov 1999 15:48:00 -0800
>From: Erich Boleyn <esboleyn@ichips.intel.com>
>To: Andrea Arcangeli <andrea@suse.de>
>Cc: Manfred Spraul <manfreds@colorfullife.com>,
> Erich Boleyn <esboleyn@ichips.intel.com>, torvalds@transmeta.com,
> linux-kernel@vger.rutgers.edu
>Subject: Re: spin_unlock optimization(i386)
[*snip*]
>For the following case:
>
> spin_lock(X);
> READ Y;
>
>...*regardless* of speculation, the value gotten by "READ Y" will be
>consistent with anything observed by the processor in "spin_lock", else
>it violates the program order, and normal programs would not work very
>well. It's perfectly OK to hoist "READ Y" above "spin_lock"
>speculatively... for example, consider the following sequence:
>
> -- processor A: "READ Y" is speculatively executed, now waiting
> to be committed to state.
> -- processor A: "spin_lock(X)" is spinning in it's loop...
> -- processor B: executes "STORE Y", then executes "spin_unlock(X)"
>
>Now NOTE:
>
> -- processor A: to observe X for the "spin_lock(X)" to succeed, it
> *must* observe "STORE Y" first.
> -- processor A: observing "STORE Y" requires it to throw away the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> speculative "READ Y" with the possibly wrong value. It may
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> attempt to reexecute "READ Y" at this time with the correct
> value.
> -- processor A: now "spin_lock(X)" can see the new value of X and
> finish.
Andrea
-
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/