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

On 06/10/2015 10:07 AM, 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:
>
> Ref: http://www.postgresql.org/message-id/4FEDE0BF.7080203@schokola.de
>
> 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.

I have played with test code that isolates a stripped down version of
s_lock() and uses it with multiple threads. I then implemented multiple
different versions of that s_lock(). The results with 200 concurrent
threads are that using a __sync_val_compare_and_swap() to acquire the
lock and then falling back to a futex() is limited to about 500,000
locks/second. Spinning for 10 times and then doing a usleep(1000) (one
millisecond) gives me 25 million locks/second.

Note that the __sync_val_compare_and_swap() GCC built in seems identical
in performance with the assembler xchgb operation used by PostgreSQL
today on x84_64.

Regards, Jan

--
Jan Wieck
Senior Software Engineer
http://slony.info