Re: Should we cacheline align PGXACT? - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: Should we cacheline align PGXACT?
Date
Msg-id CAPpHfdsPRDHgMsAeFm8AfQD14xD9=n8bf2MY15=Y8c8xTaw7yA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Should we cacheline align PGXACT?  (David Steele <david@pgmasters.net>)
List pgsql-hackers
On Wed, Mar 22, 2017 at 12:23 AM, David Steele <david@pgmasters.net> wrote:
Hi Alexander

On 3/10/17 8:08 AM, Alexander Korotkov wrote:

Results look good for me.  Idea of committing both of patches looks
attractive.
We have pretty much acceleration for read-only case and small
acceleration for read-write case.
I'll run benchmark on 72-cores machine as well.

Have you had a chance to run those tests yet?

I discovered an interesting issue.
I found that ccce90b3 (which was reverted) gives almost same effect as PGXACT alignment on read-only test on 72-cores machine.
That shouldn't be related to the functionality of ccce90b3 itself, because read-only test don't do anything with clog.  And that appears to be true.  Padding of PGPROC gives same positive effect as ccce90b3.  Padding patch (pgproc-pad.patch) is attached.  It's curious that padding changes size of PGPROC from 816 bytes to 848 bytes.  So, size of PGPROC remains 16-byte aligned.  So, probably effect is related to distance between PGPROC members...

See comparison of 16-bytes alignment of PGXACT + reduce PGXACT access vs. padding of PGPROC.

+-----------+-----------------------------+-----------------------------+-----------------------------+
|           |           master            |pgxact-align16+reduce-access |         pgproc-pad          |
|   clients |       1 |       2 |       3 |       1 |       2 |       3 |       1 |       2 |       3 |
|-----------+---------+---------+---------+---------+---------+---------+---------+---------+---------|
|         1 |   31765 |   31100 |   32961 |   32744 |   30024 |   32165 |   31831 |   31710 |   32063 |
|         2 |   58784 |   60347 |   59438 |   58900 |   60846 |   58578 |   57006 |   58875 |   59738 |
|         4 |  112786 |  116346 |  116513 |  114393 |  115238 |  116982 |  112964 |  112910 |  114248 |
|         8 |  216363 |  217180 |  220492 |  220160 |  213277 |  222844 |  219578 |  217326 |  221533 |
|        16 |  430783 |  428994 |  405667 |  441594 |  437152 |  434521 |  429309 |  430169 |  425734 |
|        20 |  531794 |  530932 |  530881 |  546216 |  536639 |  538384 |  537205 |  529382 |  535287 |
|        40 |  951640 |  930171 |  915583 |  958039 |  831028 |  932284 |  951259 |  960069 |  955081 |
|        60 | 1087248 | 1085500 | 1082603 | 1108364 | 1117380 | 1119477 | 1123136 | 1108958 | 1121190 |
|        80 | 1249524 | 1253363 | 1254437 | 1256894 | 1241449 | 1277724 | 1258509 | 1270440 | 1261364 |
|       100 | 1384761 | 1390181 | 1390948 | 1370966 | 1365666 | 1361546 | 1424189 | 1404768 | 1417215 |
|       120 | 1440615 | 1442773 | 1434149 | 1545179 | 1527888 | 1533981 | 1577170 | 1569765 | 1566950 |
|       140 | 1400715 | 1411922 | 1406841 | 1692305 | 1695125 | 1661440 | 1726416 | 1707735 | 1713590 |
|       150 | 1335935 | 1342888 | 1340833 | 1662310 | 1655399 | 1695437 | 1737758 | 1731811 | 1748215 |
|       160 | 1299769 | 1293409 | 1299178 | 1702658 | 1701668 | 1732576 | 1718459 | 1725853 | 1714432 |
|       180 | 1088828 | 1096198 | 1085467 | 1641713 | 1652604 | 1619376 | 1682716 | 1684590 | 1674715 |
|       200 |  994350 |  989267 |  996982 | 1636544 | 1650192 | 1629450 | 1654997 | 1647421 | 1646110 |
|       220 |  920877 |  922182 |  927801 | 1613027 | 1630249 | 1635628 | 1579957 | 1570928 | 1576457 |
|       240 |  887654 |  890656 |  881243 | 1565544 | 1574255 | 1570622 | 1486611 | 1496031 | 1497658 |
+-----------+---------+---------+---------+---------+---------+---------+---------+---------+---------+

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

pgsql-hackers by date:

Previous
From: Dave Page
Date:
Subject: Re: Monitoring roles patch
Next
From: Alexander Korotkov
Date:
Subject: Re: LWLock optimization for multicore Power machines