Re: Some interesting results from tweaking spinlocks - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Some interesting results from tweaking spinlocks
Date
Msg-id 200201050452.g054q6n13189@candle.pha.pa.us
Whole thread Raw
In response to Re: Some interesting results from tweaking spinlocks  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Some interesting results from tweaking spinlocks
Next
From: Tom Lane
Date:
Subject: Re: Some interesting results from tweaking spinlocks