Re: Performance TODO items - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Performance TODO items
Date
Msg-id 21804.996521352@sss.pgh.pa.us
Whole thread Raw
In response to Re: Performance TODO items  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Should we be spinning waiting for spinlock on multi-cpu machines?  Is
> that the answer?

A multi-CPU machine is actually the only case where a true spinlock
*does* make sense.  On a single CPU you might as well yield the CPU
immediately, because you have no chance of getting the lock until the
current holder is allowed to run again.  On a multi CPU it's a
reasonable guess that the current holder is running on one of the other
CPUs and may release the lock soon ("soon" == less than a process
dispatch cycle, hence busy-wait is better than release CPU).

We are currently using spinlocks for a lot of situations where the mean
time spent holding the lock is probably larger than "soon" as defined
above.  We should have a different lock implementation for those cases.
True spinlocks should be reserved for protecting code where the maximum
time spent holding the lock is guaranteed to be very short.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Performance TODO items
Next
From: "Darren King"
Date:
Subject: RE: Performance TODO items