From 04f1e3f3d95e8773f10d037bfc56a19802b449a9 Mon Sep 17 00:00:00 2001 From: Willy Tarreau Date: Wed, 28 Feb 2024 12:07:51 +0100 Subject: [PATCH] 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). --- src/ring.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/ring.c b/src/ring.c index 94ce0fe5ee..62dfa8cdd3 100644 --- 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);