Messages in this thread Patch in this message | | | From | Satyam Sharma <> | Date | Mon, 23 Jul 2007 21:36:08 +0530 | Subject | [PATCH 8/8] i386: bitops: smp_mb__{before, after}_clear_bit() definitions |
| |
From: Satyam Sharma <ssatyam@cse.iitk.ac.in>
[8/8] i386: bitops: smp_mb__{before, after}_clear_bit() definitions
From Documentation/atomic_ops.txt, those archs that require explicit memory barriers around clear_bit() must also implement these two interfaces. However, for i386, clear_bit() is a strict, locked, atomic and un-reorderable operation and includes an implicit memory barrier already.
But these two functions have been wrongly defined as "barrier()" which is a pointless _compiler optimization_ barrier, and only serves to make gcc not do legitimate optimizations that it could have otherwise done.
So let's make these proper no-ops, because that's exactly what we require these to be on the i386 platform.
Signed-off-by: Satyam Sharma <ssatyam@cse.iitk.ac.in> Cc: David Howells <dhowells@redhat.com> Cc: Nick Piggin <nickpiggin@yahoo.com.au>
---
[ A similar optimization needs to be done in the atomic.h also. Will submit that patch shortly. ]
include/asm-i386/bitops.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-i386/bitops.h b/include/asm-i386/bitops.h index 4f1fda5..42999eb 100644 --- a/include/asm-i386/bitops.h +++ b/include/asm-i386/bitops.h @@ -106,8 +106,8 @@ static inline void __clear_bit(int nr, unsigned long *addr) * Bit operations are already serializing on x86. * These must still be defined here for API completeness. */ -#define smp_mb__before_clear_bit() barrier() -#define smp_mb__after_clear_bit() barrier() +#define smp_mb__before_clear_bit() do {} while (0) +#define smp_mb__after_clear_bit() do {} while (0) /** * __change_bit - Toggle a bit in memory - 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/
| |