Re: s_lock() seems too aggressive for machines with many sockets

On Wed, Jun 10, 2015 at 11:58 AM, Andres Freund <andres@anarazel.de> wrote:
> I think we should just gank spinlocks asap. The hard part is removing
> them from lwlock.c's slow path and the buffer headers imo. After that we
> should imo be fine replacing them with lwlocks.

Mmmph.  I'm not convinced there's any point in replacing
lightly-contended spinlocks with slower, more-complex lwlocks.  But
maybe it's best to stay away from that argument and focus on getting
rid of the spinlocks that are hosing us right now.

I'm not altogether convinced that a simple replacement of spinlocks
with atomics is going to solve this problem.  If it does, great.  But
that doesn't eliminate spinning; it just moves it from the spinlock
loop to a CAS loop.  This is clearly better: when the CAS works,
you're done, as opposed to having to then manipulate the cache line
further and release the spinlock, during any of which the cache line
may get stolen from you.  However, I'm worried that it will still be
possible to create the same kinds of performance collapses that we see
with spinlocks with the CAS loops with which we place them - or even
worse problems, because clearly the spin_delay stuff *works*, and
we're unlikely to incorporate similarly sophisticated logic into every
CAS loop.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company