]> git.ipfire.org Git - thirdparty/haproxy.git/commit
MINOR: thread: provide an alternative to pthread's rwlock
authorWilly Tarreau <w@1wt.eu>
Sun, 10 Jul 2022 08:58:57 +0000 (10:58 +0200)
committerWilly Tarreau <w@1wt.eu>
Sat, 30 Jul 2022 08:17:22 +0000 (10:17 +0200)
commit87aff021dba41715d3a3e0dab9fcd685b38498da
treee08dadb7ed6ddfa0184e0dc769d630214ba0fa12
parent688709d814724037a366bebae0722b4c9b0640df
MINOR: thread: provide an alternative to pthread's rwlock

Since version 1.1.0, OpenSSL's libcrypto ignores the provided locking
mechanism and uses pthread's rwlocks instead. The problem is that for
some code paths (e.g. async engines) this results in a huge amount of
syscalls on systems facing a bit of contention, to the point where more
than 80% of the CPU can be spent in the system dealing with spinlocks
just for futex_wake().

This patch provides an alternative by redefining the relevant pthread
rwlocks from the low-overhead version of the progressive rw locks. This
way there will be no more syscalls in case of contention, and CPU will
be burnt in userland. Doing this saves massive amounts of CPU, where
the locks only take 12-15% vs 80% before, which allows SSL to work much
faster on large thread counts (e.g. 24 or more).

The tryrdlock and trywrlock variants have been implemented using a CAS
since their goal is only to succeed on no contention and never to wait.
The pthread_rwlock API is complete except that the timed versions of
the rdlock and wrlock do not wait and simply fall back to trylock
versions.

Since the gains have only been observed with async engines for now,
this option remains disabled by default. It can be enabled at build
time using USE_PTHREAD_EMULATION=1.
Makefile
src/thread.c