Re: Move PinBuffer and UnpinBuffer to atomics - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: Move PinBuffer and UnpinBuffer to atomics
Date
Msg-id CAPpHfdt1R=VF5k9fVG19GZZOQ3_HPuM9jCnM8vjJWgM7fbq2fQ@mail.gmail.com
Whole thread Raw
In response to Re: Move PinBuffer and UnpinBuffer to atomics  (Andres Freund <andres@anarazel.de>)
Responses Re: Move PinBuffer and UnpinBuffer to atomics  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
List pgsql-hackers
Hi!

On Fri, Oct 30, 2015 at 5:12 PM, Andres Freund <andres@anarazel.de> wrote:
On 2015-10-30 16:28:22 +0300, Alexander Korotkov wrote:
> pinunpin-cas-original-fix.patch is just original patch by Andres Freund
> with fixed bug which causes hang.
> Performance comparison on 72-cores Intel server in attached. On this
> machine we see no regression in version of patch in previous letter.

So pinunpin-cas-original-fix is my version with a bug fixed, and
pinunpin-cas is what exactly? Your earlier version with the xadd +
cmpxchg?

pinunpin-cas is still just cmpxchg with no xadd. It contain just minor changes:

Refactored version of atomic state patch is attached. The changes are following:
1) Macros are used for access refcount and usagecount.
2) likely/unlikely were removed. I think introducing of likely/unlikely should be a separate patch since it touches portability. Also, I didn't see any performance effect of this.
3) LockBufHdr returns the state after taking lock. Without using atomic increments it still can save some loops on skip atomic value reading.

I compare them just to show there is no regression because of these changes.
 
The results look pretty good. Could you give a few more details about
the hardware and workload (i.e. cpu model number + scale)?

It is 4 socket Intel(R) Xeon(R) CPU E7-8890 v3 @ 2.50GHz, 2 Tb of memory, all data in shared_buffers, 1000 scale factor, -M prepared, pgbench runs on the same maching through unix socket.
 
So the plan would be to finish cleaning this up into a committable
shape?

Yes.

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

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Dangling Client Backend Process
Next
From: Michael Paquier
Date:
Subject: Re: WIP: Fix parallel workers connection bug in pg_dump (Bug #13727)