Re: Some interesting results from tweaking spinlocks
От | Bruce Momjian |
---|---|
Тема | Re: Some interesting results from tweaking spinlocks |
Дата | |
Msg-id | 200201050452.g054q6n13189@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: 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: > > The difference is small, perhaps 15%. > > The thing that gets my attention is not that it's so small, it's that > it is so large. My expectation was that that code would hardly ever > be executed at all, and even less seldom (on a multiprocessor) need to > block via select(). How is it that *increasing* the delay interval > (which one might reasonably expect to simply waste cycles) can achieve > a 15% improvement in total throughput? That shouldn't be happening. 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? > > > My feeling is that we may want to start configuring whether we are on > > a multi-cpu machine and handle thing differently. > > That would be more palatable if there were some portable way of > detecting it. But maybe we'll be forced into an "is_smp" GUC switch. Yes, that is what I was thinking, but frankly, I am not going to give up on SMP auto-detection until I am convinced it can't be done portably. -- 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 по дате отправления: