Skip site navigation (1) Skip section navigation (2)

Re: Performance TODO items

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Performance TODO items
Date: 2001-07-30 19:29:12
Message-ID: 21804.996521352@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

In response to

pgsql-hackers by date

Next:From: Darren KingDate: 2001-07-30 19:32:50
Subject: RE: Performance TODO items
Previous:From: Tom LaneDate: 2001-07-30 19:24:01
Subject: Re: Performance TODO items

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group