Date: Wed, 2 Jul 2014 09:46:00 +0200
From: Andres Freund <andres@2ndquadrant.com>
To: Ants Aasma <ants@cybertec.at>
Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
 Peter Geoghegan <pg@heroku.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: better atomics - v0.5
Message-ID: <20140702074600.GH21169@awork2.anarazel.de>
References: 
 <CA+CSw_vta4=+uDhhmXjto7stc7SZrVc5NbJsJS15ZW+dP+GTug@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CA+CSw_vta4=+uDhhmXjto7stc7SZrVc5NbJsJS15ZW+dP+GTug@mail.gmail.com>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 2014-07-02 09:27:52 +0300, Ants Aasma wrote:
> On Fri, Jun 27, 2014 at 9:00 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> > Imagine the situation for the buffer header spinlock which is one of the
> > bigger performance issues atm. We could aim to replace all usages of
> > that with clever and complicated logic, but it's hard.
> >
> > The IMO reasonable (and prototyped) way to do it is to make the common
> > paths lockless, but fall back to the spinlock for the more complicated
> > situations. For the buffer header that means that pin/unpin and buffer
> > lookup are lockless, but IO and changing the identity of a buffer still
> > require the spinlock. My attempts to avoid the latter basically required
> > a buffer header specific reimplementation of spinlocks.
> 
> There is a 2010 paper [1] that demonstrates a fully non-blocking
> approach to buffer management using the same generalized clock
> algorithm that PostgreSQL has. The site also has an implementation for
> Apache Derby. You may find some interesting ideas in there.
> 
> [1] http://code.google.com/p/derby-nb/source/browse/trunk/derby-nb/ICDE10_conf_full_409.pdf

Interesting. Thanks for the link. I think I had pretty much all the
parts they described lockless as well (excluding the buffer mapping
hashtable itself, which they didn't focus on either), it was just
operations like replacing a dirty victim buffer where I fell back to the
spinlock.

Greetings,

Andres Freund

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers