Messages in this thread | | | Date | Thu, 25 Nov 1999 19:45:01 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: spin_unlock optimization(i386) |
| |
On Thu, 25 Nov 1999, Oliver Xymoron wrote:
>[..] 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/
| |