Re: Skylake-S warning - Mailing list pgsql-hackers

From Daniel Wood
Subject Re: Skylake-S warning
Date
Msg-id 421124293.166525.1538612939250@connect.xfinity.com
Whole thread Raw
In response to Re: Skylake-S warning  (Andres Freund <andres@anarazel.de>)
Responses Re: Skylake-S warning  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
One other thought.  Could we update pgxact->xmin less often?  What would be the impact of this lower bound being lower
thanit would normally be with the existing scheme.  Yes, it needs to be moved forward "occasionally".
 

FYI, be careful with padding PGXACT's to a full cache line.  With 1024 clients you'd completely blow out the L1 cache.
Thebenefits with less than 200 clients is dubious.  One problem with multiple(5) pgxact's in a single cache line is
thatyou may get a miss fetching xmin and then a second miss fetching xid because an invalidation occurs between the 2
fetchesfrom updating any of the other 5 pgxact's on the same cache line.  I've found some improvement fetching both
xminand xid with a single 64 bit fetch.  This prevents the invalidation between the two fetches.  Similarily updating
themwith a single 64 bit write helps.
 

Yes, this is uber tweaky.


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: partition tree inspection functions
Next
From: Andres Freund
Date:
Subject: Re: Skylake-S warning