Tom Lane wrote:
> I have been experimenting with altering the SPINS_PER_DELAY number in
> src/backend/storage/lmgr/s_lock.c. My results suggest that the current
> setting of 100 may be too small.
>
> The attached graph shows pgbench results on the same 4-way Linux box
> I described in my last message. (The numbers are not exactly comparable
> to the previous graph, because I recompiled with --enable-cassert off
> for this set of runs.) All runs use current CVS plus the second LWLock
> patch under discussion.
>
> Evidently, on this hardware and test case the optimal SPINS_PER_DELAY
> value is somewhere in the low thousands, not 100. I find this rather
> surprising given that spinlocks are never held for more than a few
> dozen instructions, but the results seem quite stable.
>
> On the other hand, increasing SPINS_PER_DELAY could hardly fail to be
> a loser on a single-CPU machine.
>
> Would it be worth making this value a GUC parameter, so that it could
> be tuned conveniently on a per-installation basis?
The difference is small, perhaps 15%. My feeling is that we may want to
start configuring whether we are on a multi-cpu machine and handle thing
differently. Are there other SMP issues that could be affected by a
single boolean setting? Is there a way to detect this on postmaster
startup?
My offhand opinion is that we should keep what we have now and start to
think of a more comprehensive solution for 7.3.
-- 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
