Performance: Relax atomicity constraints for crash handling

Use a store rather than a cmpxchg() for the update of the
sequential commit counter. This speeds up commit. The downside
is that short race windows between the if() check to see if the
counter is larger than the new value and the update could result
in the counter going backwards, in unlikely preemption or signal
delivery scenarios.

Accept that we may lose a few events in a crash dump for the
benefit of tracing speed.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

diff --git a/libringbuffer/frontend_internal.h b/libringbuffer/frontend_internal.h
index 43a2d0a2639b29d319ddb7b9d1d417855f9c96bc..c973e6b25f88c1cc905bedfb28463f7cc5499316 100644 (file)
--- a/libringbuffer/frontend_internal.h
+++ b/libringbuffer/frontend_internal.h
@@ -314,9 +314,9 @@ void lib_ring_buffer_write_commit_counter(const struct lttng_ust_lib_ring_buffer
                return;
 
        commit_seq_old = v_read(config, &shmp_index(handle, buf->commit_hot, idx)->seq);
-       while ((long) (commit_seq_old - commit_count) < 0)
-               commit_seq_old = v_cmpxchg(config, &shmp_index(handle, buf->commit_hot, idx)->seq,
-                                          commit_seq_old, commit_count);
+       if (caa_likely((long) (commit_seq_old - commit_count) < 0))
+               v_set(config, &shmp_index(handle, buf->commit_hot, idx)->seq,
+                       commit_count);
 }
 
 extern int lib_ring_buffer_create(struct lttng_ust_lib_ring_buffer *buf,