]> git.ipfire.org Git - thirdparty/haproxy.git/commit
OPTIM: server: get rid of the last use of _ha_barrier_full()
authorWilly Tarreau <w@1wt.eu>
Wed, 28 Jan 2026 15:59:40 +0000 (15:59 +0000)
committerWilly Tarreau <w@1wt.eu>
Wed, 28 Jan 2026 16:07:27 +0000 (16:07 +0000)
commita79a67b52f676bf84de23e2a7db43eb2f7e4380e
tree78f39a2fd99907fa63835b357a4cf9703a1f13a2
parenta9df6947b42b0f59cd5def7bd7cae3ba2d8fcb1c
OPTIM: server: get rid of the last use of _ha_barrier_full()

The code in srv_add_to_idle_list() has its roots in 2.0 with commit
9ea5d361ae ("MEDIUM: servers: Reorganize the way idle connections are
cleaned."). At this era we didn't yet have the current set of atomic
load/store operations and we used to perform loads using volatile casts
after a barrier. It turns out that this function has kept this schema
over the years, resulting in a big mfence stalling all the pipeline
in the function:

       |     static __inline void
       |     __ha_barrier_full(void)
       |     {
       |     __asm __volatile("mfence" ::: "memory");
 27.08 |       mfence
       |     if ((volatile void *)srv->idle_node.node.leaf_p == NULL) {
  0.84 |       cmpq    $0x0,0x158(%r15)
  0.74 |       je      35f
       |     return 1;

Switching these for a pair of atomic loads got rid of this and brought
0.5 to 3% extra performance depending on the tests due to variations
elsewhere, but it has never been below 0.5%. Note that the second load
doesn't need to be atomic since it's protected by the lock, but it's
cleaner from an API and code review perspective. That's also why it's
relaxed.

This was the last user of _ha_barrier_full(), let's try not to
reintroduce it now!
src/server.c