Re: Move PinBuffer and UnpinBuffer to atomics

On Tue, Feb 2, 2016 at 12:43 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:

> On 2016-02-01 13:06:57 +0300, Alexander Korotkov wrote:
> > On Mon, Feb 1, 2016 at 11:34 AM, Alexander Korotkov <
> > a(dot)korotkov(at)postgrespro(dot)ru> wrote:
> > >> Client Base Patch
> > >> 1 19744 19382
> > >> 8 125923 126395
> > >> 32 313931 333351
> > >> 64 387339 496830
> > >> 128 306412 350610
> > >>
> > >> Shared Buffer= 512MB
> > >> max_connections=150
> > >> Scale Factor=300
> > >>
> > >> ./pgbench -j$ -c$ -T300 -M prepared -S postgres
> > >>
> > >> Client Base Patch
> > >> 1 17169 16454
> > >> 8 108547 105559
> > >> 32 241619 262818
> > >> 64 206868 233606
> > >> 128 137084 217013
>
> So, there's a small regression on low client counts. That's worth
> addressing.
>

Interesting. I'll try to reproduce it.

> > Attached patch is rebased and have better comments.
> > Also, there is one comment which survive since original version by
> Andres.
> >
> > /* Add exponential backoff? Should seldomly be contended tho. */
> >
> >
> > Andres, did you mean we should twice the delay with each unsuccessful try
> > to lock?
>
> Spinning on a lock as fast as possible leads to rapid cacheline bouncing
> without anybody making progress. See s_lock() in s_lock.c.
>

I didn't notice that s_lock() behaves so. Thank you.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company