Re: Some interesting results from tweaking spinlocks

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Isn't there tons more lock contention on an SMP machine.
>
> No, one would hope not. If you can't get the various processes to
> run without much interference, you're wasting your time dealing
> with multiple CPUs.

There is hope and reality. :-)

> In a uniprocessor, we'll suffer from lock contention if one process
> happens to lose the CPU while holding a lock, and one of the other
> processes that gets to run meanwhile tries to acquire that same lock.
> In SMP this gets folded down: the lock holder might not lose its CPU
> at all, but some other CPU could be running a process that tries to
> acquire the lock meanwhile. It's not apparent to me why that should
> increase the chance of lock contention, however. The percentage of
> a process' runtime in which it is holding a lock should be the same
> either way, so the probability that another process fails to acquire
> the lock when it wants shouldn't change either. Where is the flaw
> in this analysis?

At the risk of sounding stupid because I am missing something: On a
single CPU system, one process is grabbing-releasing the lock while it
has the CPU, and sometimes it loses the CPU while it has the lock. On
an SMP machine, all the backends are contending for the lock at the
_same_ time. That is why SMP kernel coding is so hard, and they usually
get around it by having one master kernel lock, which seems to be
exactly what our mega-lock is doing; not a pretty picture.

On a single CPU machine, you fail to get the lock only if another
process has gone to sleep while holding the lock. With a multi-cpu
machine, especially a 4-way, you can have up to three processes
(excluding your own) holding that lock, and if that happens, you can't
get it.

Think of it this way, on a single-cpu machine, only one process can go
to sleep waiting on the lock. Any others will fail to get the lock and
go back to sleep. On a 4-way (which is what I think you said you were
one), you have three possible processes holding that lock, plus
processes that have gone to sleep holding the lock.

Does that make any sense?

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