tree 5d3d36437e4a90d723fe30b01397c7560777589b
parent cb0451146f2ce4bf8a93890c403262b5308608a4
author Willy Tarreau <w@1wt.eu> 1626357767 +0200
committer Willy Tarreau <w@1wt.eu> 1627832046 +0200
encoding latin1

MEDIUM: atomic: relax the load/store barriers on x86_64

The x86-tso model makes the load and store barriers unneeded for our
usage as long as they perform at least a compiler barrier: the CPU
will respect store ordering and store vs load ordering. It's thus
safe to remove the lfence and sfence which are normally needed only
to communicate with external devices. Let's keep the mfence though,
to make sure that reads of same memory location after writes report
the value from memory and not the one snooped from the write buffer
for too long.

An in-depth review of all use cases tends to indicate that this is
okay in the rest of the code. Some parts could be cleaned up to
use atomic stores and atomic loads instead of explicit barriers
though.

Doing this reliably increases the overall performance by about 2-2.5%
on a 8c-16t Xeon thanks to less frequent flushes (it's likely that the
biggest gain is in the MT lists which use them a lot, and that this
results in less cache line flushes).