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

From: Nils Goroll <slink(at)schokola(dot)de>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jan Wieck <jan(at)wi3ck(dot)info>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: s_lock() seems too aggressive for machines with many sockets
Date: 2015-06-10 15:12:56
Message-ID: 557853F8.9090406@schokola.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/06/15 17:01, Andres Freund wrote:
>> > - The fact that well behaved mutexes have a higher initial cost could even
>> > motivate good use of them rather than optimize misuse.
> Well. There's many locks in a RDBMS that can't realistically be
> avoided. So optimizing for no and moderate contention isn't something
> you can simply forgo.

Let's get back to my initial suggestion:

On 10/06/15 16:07, Nils Goroll wrote:
> 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.

Where we use the mutex patch we have not seen any relevant negative impact -
neither in benchmarks nor in production.

So, yes, postgres should still work fine on a 2-core laptop and I don't see any
reason why using posix mutexes *where they are known to behave* would do any harm.

And, to be honest, Linux is quite dominant, so solving the issue for this
platform would be a start at least.

Nils

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nils Goroll 2015-06-10 15:16:39 Re: s_lock() seems too aggressive for machines with many sockets
Previous Message Jan Wieck 2015-06-10 15:12:46 Re: s_lock() seems too aggressive for machines with many sockets