Re: better atomics - v0.2

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Ants Aasma <ants(at)cybertec(dot)at>
Subject: Re: better atomics - v0.2
Date: 2013-11-19 22:34:01
Message-ID: 20131119223401.GB6591@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Paul Ramsey 2013-11-19 22:40:00 Traffic jams in fn_extra
Previous Message Bruce Momjian 2013-11-19 22:25:21 Re: better atomics - v0.2