This patch enables atomics on x64 builds.

Reuse the atomics defined for x86 and add atomics for 64 bit reads/writes.

Before this patch the cmap test gives us:
$ ./tests/ovstest.exe test-cmap benchmark 10000000 3 1
Benchmarking with n=10000000, 3 threads, 1.00% mutations, batch size 1:
cmap insert:  20100 ms
cmap iterate:  2967 ms
batch search: 10929 ms
cmap destroy: 13489 ms

cmap insert:  20079 ms
cmap iterate:  2953 ms
cmap search:  10559 ms
cmap destroy: 13486 ms

hmap insert:   2021 ms
hmap iterate:  1162 ms
hmap search:   5152 ms
hmap destroy:  1158 ms

After this change we have:
$ ./tests/ovstest.exe test-cmap benchmark 10000000 3 1
Benchmarking with n=10000000, 3 threads, 1.00% mutations, batch size 1:
cmap insert:   2953 ms
cmap iterate:   267 ms
batch search:  2193 ms
cmap destroy:  2037 ms

cmap insert:   2909 ms
cmap iterate:   267 ms
cmap search:   2167 ms
cmap destroy:  2087 ms

hmap insert:   1853 ms
hmap iterate:  1086 ms
hmap search:   4395 ms
hmap destroy:  1140 ms

We should probably revisit this file and investigate it further to see if
we can squeeze more performance.

As a side effect fix tests on x64 because usage of `ovs-atomic-pthreads.h`
is currently broken.

Signed-off-by: Alin Gabriel Serdean <[email protected]>
Suggested-by: Ben Pfaff <[email protected]>
---
v2: Change commit message.
---
 lib/ovs-atomic-msvc.h | 12 ++++++++++++
 lib/ovs-atomic.h      |  2 +-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/lib/ovs-atomic-msvc.h b/lib/ovs-atomic-msvc.h
index c6a7db3..0b041c6 100644
--- a/lib/ovs-atomic-msvc.h
+++ b/lib/ovs-atomic-msvc.h
@@ -107,6 +107,7 @@ atomic_signal_fence(memory_order order)
  * InterlockedExchange64Acquire() available. So we are forced to use
  * InterlockedExchange64() which uses full memory barrier for everything
  * greater than 'memory_order_relaxed'. */
+#ifdef _M_IX86
 #define atomic_store64(DST, SRC, ORDER)                                    \
     if (ORDER == memory_order_relaxed) {                                   \
         InterlockedExchangeNoFence64((int64_t volatile *) (DST),           \
@@ -114,6 +115,11 @@ atomic_signal_fence(memory_order order)
     } else {                                                               \
         InterlockedExchange64((int64_t volatile *) (DST), (int64_t) (SRC));\
     }
+#elif _M_X64
+/* 64 bit writes are atomic on amd64 if 64 bit aligned. */
+#define atomic_store64(DST, SRC, ORDER)                                 \
+    atomic_storeX(64, DST, SRC, ORDER)
+#endif
 
 /* Used for 8 and 16 bit variations. */
 #define atomic_storeX(X, DST, SRC, ORDER)                               \
@@ -160,11 +166,17 @@ atomic_signal_fence(memory_order order)
 /* MSVC converts 64 bit reads into two instructions. So there is
  * a possibility that an interrupt can make a 64 bit read non-atomic even
  * when 8 byte aligned. So use fully memory barrier InterlockedOr64(). */
+#ifdef _M_IX86
 #define atomic_read64(SRC, DST, ORDER)                                     \
     __pragma (warning(push))                                               \
     __pragma (warning(disable:4047))                                       \
     *(DST) = InterlockedOr64((int64_t volatile *) (SRC), 0);               \
     __pragma (warning(pop))
+#elif _M_X64
+/* 64 bit reads are atomic on amd64 if 64 bit aligned. */
+#define atomic_read64(SRC, DST, ORDER)                                     \
+    *(DST) = *(SRC);
+#endif
 
 #define atomic_read(SRC, DST)                               \
         atomic_read_explicit(SRC, DST, memory_order_seq_cst)
diff --git a/lib/ovs-atomic.h b/lib/ovs-atomic.h
index f1f2c38..c835eb7 100644
--- a/lib/ovs-atomic.h
+++ b/lib/ovs-atomic.h
@@ -335,7 +335,7 @@
         #include "ovs-atomic-i586.h"
     #elif HAVE_GCC4_ATOMICS
         #include "ovs-atomic-gcc4+.h"
-    #elif _MSC_VER && _M_IX86 >= 500
+    #elif _MSC_VER
         #include "ovs-atomic-msvc.h"
     #else
         /* ovs-atomic-pthreads implementation is provided for portability.
-- 
2.10.2.windows.1

_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to