mirror of
http://git.haproxy.org/git/haproxy.git/
synced 2025-01-09 23:39:55 +00:00
99198546f6
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). |
||
---|---|---|
.. | ||
haproxy | ||
import |