From: | Nils Goroll <slink(at)schokola(dot)de> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | 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 14:55:31 |
Message-ID: | 55784FE3.6060906@schokola.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/06/15 16:20, Andres Freund wrote:
> That's precisely what I referred to in the bit you cut away...
I apologize, yes.
On 10/06/15 16:25, Tom Lane wrote:
> Optimizing for misuse of the mechanism is not the way.
I absolutely agree and I really appreciate all efforts towards lockless data
structures or at least better concurrency using classical mutual exclusion.
But still I am convinced that on today's massively parallel NUMAs, spinlocks are
plain wrong:
- Even if critical sections are kept minimal, they can still become hot spots
- When they do, we get potentially massive negative scalability, it will be
hard to exclude the possibility of a system "tilting" under (potentially yet
unknown) load patterns as long as userland slocks exist.
Briefly: When slocks fail, they fail big time
- slocks optimize for the best case, but I think on today's systems we should
optimize for the worst case.
- The fact that well behaved mutexes have a higher initial cost could even
motivate good use of them rather than optimize misuse.
Cheers,
Nils
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-06-10 14:56:06 | Re: s_lock() seems too aggressive for machines with many sockets |
Previous Message | Jan Wieck | 2015-06-10 14:54:11 | Re: s_lock() seems too aggressive for machines with many sockets |