Re: Some interesting results from tweaking spinlocks
От | Bruce Momjian |
---|---|
Тема | Re: Some interesting results from tweaking spinlocks |
Дата | |
Msg-id | 200201050608.g0568dm03340@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Some interesting results from tweaking spinlocks (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.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@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: