> >locked memory operations _are_ serializing instructions (spinlocks would
>
> No. They are serializing only _reads_ in memory (writes are ordered by
> default).
they 'drain' the write queue, which _is_ synchronization. Writes _are_
being reordered, typically with reads. Also, writes to the same target in
the write queue are getting merged as well. You can fully expect that if
ever an IA32 CPU does write<->write reordering (cache coherent one, not
WC), LOCK-ed instruction will be a barrier for them.
> Here a cut-and-paste of an Intel spec:
> · Instruction fetch may pass locked operations like XCHG
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> · Instruction fetch may not pass serializing instructions
> ^^^ ^^^^^^^^^^^^^^^^^^^^^^^^
We dont worry about instruction fetch, only in a special type of (very
rare) self-modifying code that does the modification through alias
mappings. The above quote is misleading, use this description instead:
'Locked operations are atomic with respect to all other memory operations
and all externally visible events. Only instruction fetch and page table
accesses can pass locked instructions. Locked instructions can be used to
synchronize data written by one processor and read by another processor.
For the P6 family processors, locked operations serialize all outstanding
load and store operations (that is, wait for them to complete).'
(and as i told you in the previous mail, even instruction prefetch and
page table access is properly synchronized in Linux, because we use invlpg
and iret)
-- mingo
-
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/