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

On 2015-06-10 10:25:32 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > Unfortunately there's no portable futex support. That's what stopped us
> > from adopting them so far. And even futexes can be significantly more
> > heavyweight under moderate contention than our spinlocks - It's rather
> > easy to reproduce scenarios where futexes cause significant slowdown in
> > comparison to spinning in userspace (just reproduce contention on a
> > spinlock where the protected area will be *very* short - i.e. no cache
> > misses, no branches or such).
>
> Which, you'll note, is the ONLY case that's allowed by our coding rules
> for spinlock use. If there are any locking sections that are not very
> short straight-line code, or at least code with easily predicted branches,
> we need to fix those before we worry about the spinlock mechanism per
> se.

We haven't followed that all that strictly imo. While lwlocks are a bit
less problematic in 9.5 (as they take far fewer spinlocks), they're
still far from perfect as we manipulate linked lists while holding a
lock. We malso do lots of hard to predict stuff while the buffer header
spinlock is held...

> Optimizing for misuse of the mechanism is not the way.

Agreed. I'm not particularly interested in optimizing spinlocks. We
should get rid of most.

Greetings,

Andres Freund