urcu: add cacheline padding to URCU thread data
authorTodd Lipcon <todd@cloudera.com>
Fri, 21 Apr 2017 23:01:47 +0000 (16:01 -0700)
committerkhizmax <libcds.dev@gmail.com>
Sun, 23 Apr 2017 17:15:53 +0000 (20:15 +0300)
The thread-local data was previously smaller than a cacheline, so it was
possible for multiple thread's thread data to be allocated on the same
cacheline and cause false sharing.

I measured the offcore_response.all_data_rd.l3_hit.hitm_other_core
perf counter in a read-only workload with 16 threads executing a
read-only workload against a URCU-protected split-list set. Before, I
saw about 5.6M events per second. After, I saw basically none.

Additionally, 'perf c2c' showed a lot of cache-line bouncing in the URCU
read side critical section before, but now shows none.

I benchmarked the above read-only workload on a machine with 88 logical
cores (Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz) and 88 threads, and
the performance improved more than 2x.

Fixes issue #75

cds/urcu/details/gp_decl.h

index 52592c8a1b924b2a2710e8349160f3d9fa1f739b..dcfe0a228cecde7e701816bc430ea4f152877173 100644 (file)
@@ -34,6 +34,7 @@
 #include <cds/urcu/details/base.h>
 #include <cds/details/static_functor.h>
 #include <cds/details/lib.h>
+#include <cds/user_setup/cache_line.h>
 
 //@cond
 namespace cds { namespace urcu { namespace details {
@@ -45,6 +46,7 @@ namespace cds { namespace urcu { namespace details {
     template <> struct thread_data<tag_> { \
         atomics::atomic<uint32_t>        m_nAccessControl ; \
         thread_list_record< thread_data >   m_list ; \
+        char pad_[cds::c_nCacheLineSize]; \
         thread_data(): m_nAccessControl(0) {} \
         explicit thread_data( OS::ThreadId owner ): m_nAccessControl(0), m_list(owner) {} \
         ~thread_data() {} \