Re: [PATCH 8/8] i386: bitops: smp_mb__{before, after}_clear_bit() definitions
- From: Satyam Sharma <ssatyam@xxxxxxxxxxxxxx>
- Date: Tue, 24 Jul 2007 16:40:09 +0530 (IST)
On Tue, 24 Jul 2007, Nick Piggin wrote:
Satyam Sharma wrote:
only for clear_bit(),Consider this (the above two functions exist
_only_ memory referencethe atomic variant, as you already know), the
passed bit-string:we care about is that of the address of the
memory references.
No. Memory barriers explicitly extend to all
[ Compiler barrier, you mean, that's not true of CPU
barriers. ]
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.
Obviously because we want some kind of ordering
guarantee at a given point. All the CPU barriers
in the world are useless if the compiler can reorder
access over them.
Yes ...
As for a compiler barrier, the asm there already
guarantees the compiler
will not optimize references to _that_ address
One or both of us still fails to understand the other.
... I think the culprit is me ...
bit_spin_lock(LOCK_NR, &word);
var++;
/* this is bit_spin_unlock(LOCK_NR, &word); */
smp_mb__before_clear_bit();
clear_bit(LOCK_NR, &word);
Yup, David has laid this out clearly, as well.
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.
Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- References:
- Prev by Date: 2.6.22.1: OOps during shutdown: ( kernel not tained now)
- Next by Date: Re: [patch] mm: reduce pagetable-freeing latencies
- Previous by thread: Re: [PATCH 8/8] i386: bitops: smp_mb__{before, after}_clear_bit() definitions
- Next by thread: Re: [PATCH 8/8] i386: bitops: smp_mb__{before, after}_clear_bit() definitions
- Index(es):
Relevant Pages
|
