MINOR: ring: don't take the readers lock if there are no readers

There's no point looking for freshly attached readers if there are none,
taking this lock requires an atomic write to a shared area, something we
clearly want to avoid.

A general test with 213-byte messages on different thread counts shows
how the performance degrades across CCX and how this patch improves the
situation:
                   Before          After
    3C6T/1CCX:    6.39 Mmsg/s     6.35 Mmsg/s
   6C12T/2CCX:    2.90 Mmsg/s     3.16 Mmsg/s
  12C24T/4CCX:    2.14 Mmsg/s     2.33 Mmsg/s
  24C48T/8CCX:    1.75 Mmsg/s     1.92 Mmsg/s

This tends to confirm that the queues will really be needed and that
they'll have to be per-ccx hence per thread-group. They will amortize
the number of updates on head & tail (one per multiple messages).

diff --git a/src/ring.c b/src/ring.c
index 94ce0fe5ee4a5d8b4b2513c633b2129d43b5bda5..62dfa8cdd30abf513d21203b51329ef79a2298b3 100644 (file)
--- a/src/ring.c
+++ b/src/ring.c
@@ -339,7 +339,7 @@ ssize_t ring_write(struct ring *ring, size_t maxlen, const struct ist pfx[], siz
        HA_ATOMIC_STORE(lock_ptr, readers);
 
        /* notify potential readers */
-       if (sent) {
+       if (sent && HA_ATOMIC_LOAD(&ring->readers_count)) {
                HA_RWLOCK_RDLOCK(RING_LOCK, &ring->lock);
                list_for_each_entry(appctx, &ring->waiters, wait_entry)
                        appctx_wakeup(appctx);