Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1307871

[PATCH v2 1/3] x86: drop mfence in favor of lock+addl

From "Michael S. Tsirkin" <mst@redhat.com>
Newsgroups linux.kernel
Subject [PATCH v2 1/3] x86: drop mfence in favor of lock+addl
Date 2016-01-12 23:20 +0100
Message-ID <qQfsd-7eN-1@gated-at.bofh.it> (permalink)
References <qQfsd-7eN-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


mfence appears to be way slower than a locked instruction - let's use
lock+add unconditionally, same as we always did on old 32-bit.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
 arch/x86/include/asm/barrier.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
index a584e1c..7f99726 100644
--- a/arch/x86/include/asm/barrier.h
+++ b/arch/x86/include/asm/barrier.h
@@ -15,11 +15,12 @@
  * Some non-Intel clones support out of order store. wmb() ceases to be a
  * nop for these.
  */
-#define mb() alternative("lock; addl $0,0(%%esp)", "mfence", X86_FEATURE_XMM2)
+
+#define mb() asm volatile("lock; addl $0,0(%%esp)" ::: "memory")
 #define rmb() alternative("lock; addl $0,0(%%esp)", "lfence", X86_FEATURE_XMM2)
 #define wmb() alternative("lock; addl $0,0(%%esp)", "sfence", X86_FEATURE_XMM)
 #else
-#define mb() 	asm volatile("mfence":::"memory")
+#define mb() asm volatile("lock; addl $0,0(%%rsp)" ::: "memory")
 #define rmb()	asm volatile("lfence":::"memory")
 #define wmb()	asm volatile("sfence" ::: "memory")
 #endif
-- 
MST

Back to linux.kernel | Previous | Next | Find similar | Unroll thread


Thread

[PATCH v2 1/3] x86: drop mfence in favor of lock+addl "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-12 23:20 +0100

csiph-web