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

On 2015-06-10 16:07:50 +0200, Nils Goroll wrote:
> On larger Linux machines, we have been running with spin locks replaced by
> generic posix mutexes for years now. I personally haven't look at the code for
> ages, but we maintain a patch which pretty much does the same thing still:

Interesting. I've been able to reproduce quite massive slowdowns doing
this on a 4 socket linux machine (after applying the lwlock patch that's
now in 9.5) in readonly workloads. As in 200%+ slower. And that was with
a new kernel/glibc.  That was primarily due to buffer header
spinlocks. For write workloads the difference was smaller, but still
noticeably. There xlog.c's spinlocks where noticeable which are usually
held very shortly.

> Ref: http://www.postgresql.org/message-id/4FEDE0BF.7080203@schokola.de

Do you have any details about the workloads that scaled badly back then?
It'd be interesting to find out which spinlocks they bottlenecked
on.

> I understand that there are systems out there which have less efficient posix
> mutex implementations than Linux (which uses futexes), but I think it would
> still be worth considering to do away with the roll-your-own spinlocks on
> systems whose posix mutexes are known to behave.

If we get rid of the 'hot' spinlocks something very roughly like this
will possibly be realistic (we can't rely on pthreads, but ...). I don't
think it'll be before that.