Gitweb:     
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b6c7347fffa655a3000d9d41640d222c19fc3065
Commit:     b6c7347fffa655a3000d9d41640d222c19fc3065
Parent:     4071c718555d955a35e9651f77086096ad87d498
Author:     Nick Piggin <[EMAIL PROTECTED]>
AuthorDate: Sat Oct 13 03:07:38 2007 +0200
Committer:  Linus Torvalds <[EMAIL PROTECTED]>
CommitDate: Fri Oct 12 18:41:21 2007 -0700

    x86: optimise barriers
    
    According to latest memory ordering specification documents from Intel
    and AMD, both manufacturers are committed to in-order loads from
    cacheable memory for the x86 architecture.  Hence, smp_rmb() may be a
    simple barrier.
    
    Also according to those documents, and according to existing practice in
    Linux (eg.  spin_unlock doesn't enforce ordering), stores to cacheable
    memory are visible in program order too.  Special string stores are safe
    -- their constituent stores may be out of order, but they must complete
    in order WRT surrounding stores.  Nontemporal stores to WB memory can go
    out of order, and so they should be fenced explicitly to make them
    appear in-order WRT other stores.  Hence, smp_wmb() may be a simple
    barrier.
    
        http://developer.intel.com/products/processor/manuals/318147.pdf
        
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf
    
    In userspace microbenchmarks on a core2 system, fence instructions range
    anywhere from around 15 cycles to 50, which may not be totally
    insignificant in performance critical paths (code size will go down
    too).
    
    However the primary motivation for this is to have the canonical barrier
    implementation for x86 architecture.
    
    smp_rmb on buggy pentium pros remains a locked op, which is apparently
    required.
    
    Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
    Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
---
 include/asm-x86/system_32.h |    6 +++++-
 include/asm-x86/system_64.h |    4 ++--
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/include/asm-x86/system_32.h b/include/asm-x86/system_32.h
index 8b15bd3..e7e5d42 100644
--- a/include/asm-x86/system_32.h
+++ b/include/asm-x86/system_32.h
@@ -274,7 +274,11 @@ static inline unsigned long get_limit(unsigned long 
segment)
 
 #ifdef CONFIG_SMP
 #define smp_mb()       mb()
-#define smp_rmb()      rmb()
+#ifdef CONFIG_X86_PPRO_FENCE
+# define smp_rmb()     rmb()
+#else
+# define smp_rmb()     barrier()
+#endif
 #ifdef CONFIG_X86_OOSTORE
 # define smp_wmb()     wmb()
 #else
diff --git a/include/asm-x86/system_64.h b/include/asm-x86/system_64.h
index eff730b..5022aec 100644
--- a/include/asm-x86/system_64.h
+++ b/include/asm-x86/system_64.h
@@ -141,8 +141,8 @@ static inline void write_cr8(unsigned long val)
 
 #ifdef CONFIG_SMP
 #define smp_mb()       mb()
-#define smp_rmb()      rmb()
-#define smp_wmb()      wmb()
+#define smp_rmb()      barrier()
+#define smp_wmb()      barrier()
 #define smp_read_barrier_depends()     do {} while(0)
 #else
 #define smp_mb()       barrier()
-
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to