Re: better atomics - v0.5

On 2014-07-02 09:27:52 +0300, Ants Aasma wrote:
> On Fri, Jun 27, 2014 at 9:00 PM, Andres Freund <andres(at)2ndquadrant(dot)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