Re: Some interesting results from tweaking spinlocks

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > OK, I am a little confused now. I thought the spinlock was only done a
> > few times if we couldn't get a lock, and if we don't we go to sleep, and
> > the count determines how many times we try. Isn't that expected to
> > affect SMP machines?
>
> Yeah, but if the spinlock is only held for a few dozen instructions,
> one would think that the max useful delay is also a few dozen
> instructions (or maybe a few times that, allowing for the possibility
> that other processors might claim the lock before we can get it).
> If we spin for longer than that, the obvious conclusion is that the
> spinlock is held by a process that's lost the CPU, and we should
> ourselves yield the CPU so that it can run again. Further spinning
> just wastes CPU time that might be used elsewhere.
>
> These measurements seem to say there's a flaw in that reasoning.
> What is the flaw?

My guess is that the lock is held for more than a few instructions, at
least in some cases. Spin/increment is a pretty fast operation with no
access of RAM. Could the overhead of the few instructions be more than
the spin time, or perhaps there is a stall in the cpu cache, requiring
slower RAM access while the spin counter is incrementing rapidly?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026