Hi, On 2024-04-10 21:52:59 -0400, Tom Lane wrote: > Less drastically, I wonder if we should call finish_spin_delay > at all in these off-label uses of perform_spin_delay. What > we're trying to measure there is the behavior of TAS() spin loops, > and I'm not sure that what LWLockWaitListLock and the bufmgr > callers are doing should be assumed to have timing behavior > identical to that.
I think the difference between individual spinlocks is bigger than between spinlocks and lwlock/buffer header locks. I think we probably should move away from having any spinlocks. I tried to just replace them with lwlocks, but today the overhead is too big. The issue isn't primarily the error handling or such, but the fact that rwlocks are more expensive than simple exclusive locks. The main differences are: 1) On x86 a spinlock release just needs a compiler barrier, but an rwlock needs an atomic op. 2) Simple mutex acquisition is easily done with an atomic-exchange, which is much harder for an rwlock (as the lock has more states, so just setting to "locked" and checking the return value isn't sufficient). Once a lock is contended, a atomic compare-exchange ends up with lots of retries due to concurrent changes. It might be that we can still get away with just removing spinlocks - to my knowledge we have one very heavily contended performance critical spinlock, XLogCtl->Insert->insertpos_lck. I think Thomas and I have come up with a way to do away with that spinlock. OTOH, there are plenty other lwlocks where we pay the price of lwlocks being an rwlock, but just use the exclusive mode. So perhaps we should just add a exclusive-only lwlock variant. Greetings, Andres Freund