From: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | YUriy Zhuravlev <u(dot)zhuravlev(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Move PinBuffer and UnpinBuffer to atomics |
Date: | 2015-10-30 14:46:59 |
Message-ID: | CAPpHfdt1R=VF5k9fVG19GZZOQ3_HPuM9jCnM8vjJWgM7fbq2fQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi!
On Fri, Oct 30, 2015 at 5:12 PM, Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2015-10-30 14:48:25 | Re: WIP: Fix parallel workers connection bug in pg_dump (Bug #13727) |
Previous Message | Andres Freund | 2015-10-30 14:46:35 | Re: Dangling Client Backend Process |