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