Dave Cramer <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster