Dave Cramer <pg@fastcrypt.com> writes:
> My hypothesis is that if you spin approximately the same or more time
> than the average time it takes to get finished with the shared resource
> then this should reduce cs.
The only thing we use spinlocks for nowadays is to protect LWLocks, so
the "average time" involved is fairly small and stable --- or at least
that was the design intention. What we seem to be seeing is that on SMP
machines, cache coherency issues cause the TAS step itself to be
expensive and variable. However, in the experiments I did, strace'ing
showed that actual spin timeouts (manifested by the execution of a
delaying select()) weren't actually that common; the big source of
context switches is semop(), which indicates contention at the LWLock
level rather than the spinlock level. So while tuning the spinlock
limit count might be a useful thing to do in general, I think it will
have only negligible impact on the particular problems we're discussing
in this thread.
regards, tom lane
