Re: better atomics - v0.2

Andres Freund <andres@2ndquadrant.com>

From: Andres Freund <andres@2ndquadrant.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>, Robert Haas <robertmhaas@gmail.com>, Peter Geoghegan <pg@heroku.com>, Pg Hackers <pgsql-hackers@postgresql.org>, Ants Aasma <ants@cybertec.at>
Date: 2013-11-19T22:34:01Z
Lists: pgsql-hackers
On 2013-11-19 17:25:21 -0500, Bruce Momjian wrote:
> On Tue, Nov 19, 2013 at 11:21:06PM +0100, Andres Freund wrote:
> > On 2013-11-19 17:16:56 -0500, Bruce Momjian wrote:
> > > On Tue, Nov 19, 2013 at 10:39:19PM +0100, Andres Freund wrote:
> > Do you mean inline? Or atomics? If the former no, if the latter
> > yes. I've started on it because of
> > http://archives.postgresql.org/message-id/20130926225545.GB26663%40awork2.anarazel.de
> 
> Yes, I was wondering about atomics.  I think we know the performance
> characteristics of inlining.

In that case it really depends on what we do with the atomics, providing
the abstraction itself shouldn't change performance at all, but the
possible scalability wins of using them in some critical paths are
pretty huge.

From a prototype I have, ontop of the number in the above post, removing
the spinlock from PinBuffer and UnpinBuffer() (only the
!BM_PIN_COUNT_WAITER path) gives another factor of two on the used
machine, although that required limiting MAX_BACKENDS to 0xfffff instead
of the current 0x7fffff.

Greetings,

Andres Freund

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


Commits

  1. Avoid the use of a separate spinlock to protect a LWLock's wait queue.

  2. Improve LWLock scalability.

  3. Reduce the number of semaphores used under --disable-spinlocks.

  4. Alter the configure script to fail immediately if the C compiler does not