> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > What you want to do is to wake up the sleeper but not give them the lock
> > until they are actually running and can aquire it themselves.
>
> Yeah. Essentially this is a partial reversion to the idea of a
> spinlock. But it's more efficient than our old implementation with
> timed waits between retries, because (a) a process will not be awoken
> unless it has a chance at getting the lock, and (b) when a contended-for
> lock is freed, a waiting process will be made ready immediately, rather
> than waiting for a time tick to elapse. So, if the lock-releasing
> process does block before the end of its quantum, the released process
> is available to run immediately. Under the old scheme, a process that
> had failed to get a spinlock couldn't run until its select wait timed
> out, even if the lock were now available. So I think it's still a net
> win to have the LWLock mechanism in there, rather than just changing
> them back to spinlocks.
>
> > If you code up a patch, I will test it on my SMP machine using pgbench.
> > Hopefully this will help Tatsuo's 4-way AIX machine too, and Linux.
>
> Attached is a proposed patch (against the current-CVS version of
> lwlock.c). I haven't committed this yet, but it seems to be a win on
> a single CPU. Can people try it on multi CPUs?
OK, here are the results on BSD/OS 4.2 on a 2-cpu system. The first is
before the patch, the second after. Both average 14tps, so the patch
has no negative effect on my system. Of course, it has no positive
effect either. :-)
--
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