On Thu, Sep 11, 2014 at 4:22 PM, Andres Freund <and...@2ndquadrant.com> wrote: >> > Hm. Perhaps we should do a bufHdr->refcount != zero check without >> > locking here? The atomic op will transfer the cacheline exclusively to >> > the reclaimer's CPU. Even though it very shortly afterwards will be >> > touched afterwards by the pinning backend. >> >> Meh. I'm not in favor of adding more funny games with locking unless >> we can prove they're necessary for performance. > > Well, this in theory increases the number of processes touching buffer > headers regularly. Currently, if you have one read IO intensive backend, > there's pretty much only process touching the cachelines. This will make > it two. I don't think it's unreasonable to try to reduce the cacheline > pingpong caused by that...
I don't think it will help much. A pinned buffer is pretty likely to be in modified state in the cache of the cpu of the pinning backend. Even taking a look at the refcount will trigger a writeback and demotion to shared state. When time comes to unpin the buffer the cacheline must again be promoted to exclusive state introducing coherency traffic. Not locking the buffer only saves transfering the cacheline back to the pinning backend, not a huge amount of savings. Regards, Ants Aasma -- Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
