Messages in this thread | | | Date | Tue, 24 Jul 2007 21:32:54 +1000 | From | Nick Piggin <> | Subject | Re: [PATCH 8/8] i386: bitops: smp_mb__{before, after}_clear_bit() definitions |
| |
Satyam Sharma wrote: > On Tue, 24 Jul 2007, Nick Piggin wrote: >
>>For the purpose of this discussion (Linux memory >>barrier semantics, on WB memory), it is true of CPU >>and compiler barriers. > > > On later Intel processors, if the memory address range being referenced > (and say written to) by the (locked) instruction is in the cache of a > CPU, then it will not assert the LOCK signal on the system bus -- > thus not assume exclusive use of shared memory. So other CPUs are free > to modify (other) memory at that point. Cache coherency will still > ensure _that_ (locked) memory area is still updated atomically, though.
The system bus does not need to be serialised because the CPU already holds the cacheline in exclusive state. That *is* the cache coherency protocol.
The memory ordering is enforced by the CPU effectively preventing speculative loads to pass the locked instruction and ensuring all stores reach the cache before it is executed. (I say effectively because the CPU might do clever tricks without you knowing).
>>Are you saying that it is OK for the store to var to >>be reordered below the clear_bit? If not, what are you >>saying? > > > I might be making a radical turn-around here, but all of a > sudden I think it's actually a good idea to put a complete > memory clobber in set_bit/clear_bit and friends themselves, > and leave the "__" variants as they are.
Why?
-- SUSE Labs, Novell Inc. - 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/
| |