Re: Spinlock performance improvement proposal

> We have been doing some scalability testing just recently here at Red
> Hat. The machine I was using was a 4-way 550 MHz Xeon SMP machine, I
> also ran the machine in uniprocessor mode to make some comparisons. All
> runs were made on Red Hat Linux running 2.4.x series kernels. I've
> examined a number of potentially interesting cases -- I'm still
> analyzing the results, but some of the initial results might be
> interesting:

Let me add a little historical information here. I think the first
report of bad performance on SMP machines was from Tatsuo, where he had
1000 backends running in pgbench. He was seeing poor
transactions/second with little CPU or I/O usage. It was clear
something was wrong.

Looking at the code, it was easy to see that on SMP machines, the
spinlock select() was a problem. Later tests on various OS's found that
no matter how small your select interval was, select() couldn't sleep
for less than one cpu tick, which is tyically 100Hz or 10ms. At that
point we knew that the spinlock backoff code was a serious problem. On
multi-processor machines that could hit the backoff code on lock
failure, there where hudreds of threads sleeping for 10ms, then all
waking up, one gets the lock, and the others sleep again.

On single-cpu machines, the backoff code doesn't get hit too much, but
it is still a problem. Tom's implementation changes backoffs in all
cases by placing them in a semaphore queue and reducing the amount of
code protected by the spinlock.

We have these TODO items out of this:

* Improve spinlock code [performance]
o use SysV semaphores or queue of backends waiting on the lock
o wakeup sleeper or sleep for less than one clock tick
o spin for lock on multi-cpu machines, yield on single cpu machines
o read/write locks

--
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