MEDIUM: ring: use the topmost bit of the tail as a lock
authorWilly Tarreau <w@1wt.eu>
Wed, 28 Feb 2024 08:37:47 +0000 (09:37 +0100)
committerWilly Tarreau <w@1wt.eu>
Mon, 25 Mar 2024 17:34:19 +0000 (17:34 +0000)
commiteb3d5f464d5f90c18c488d5025982e0c59cc5416
tree88068a034be9669f0b682ccf5ee150f0f4bdea5c
parent2192983ffd6ca0dbfae245ba1fdd90d768f1b89c
MEDIUM: ring: use the topmost bit of the tail as a lock

We're now locking the tail while looking for some room in the ring. In
fact it's still while writing to it, but the goal definitely is to get
rid of the lock ASAP. For this we reserve the topmost bit of the tail
as a lock, which may have as a possible visible effect that buffers will
be limited to 2GB instead of 4GB on 32-bit machines (though in practise,
good luck for allocating more than 2GB contiguous on 32-bit), but in
practice since the size is read with atol() and some operating systems
limit it to LONG_MAX unless passing negative numbers, the limit is
already there.

For now the impact on x86_64 is significant (drop from 2.35 to 1.4M/s
on 48 threads on EPYC 24 cores) but this situation is only temporary
so that changes can be reviewable and bisectable.

Other approaches were attempted, such as using XCHG instead, which is
slightly faster on x86 with low thread counts (but causes more write
contention), and forces readers to stall under heavy traffic because
they can't access a valid value for the queue anymore. A CAS requires
preloading the value and is les good on ARMv8.1. XADD could also be
considered with 12-13 upper bits of the offset dedicated to locking,
but that looks overkill.
dev/haring/haring.c
include/haproxy/ring-t.h
include/haproxy/ring.h
src/ring.c
src/sink.c