Nils Goroll <sl...@schokola.de> writes:
> How I read this under the assumption that the test was correct and valid _and_
> can be reproduced independently:
> * for very low concurrency, the existing spinlock implementation is ideal -
> we can't do any better both in terms of resulting sps and resource
> consumption.
> One path to explore here would be PTHREAD_MUTEX_ADAPTIVE_NP, which
> essentially
> is the same as a spinlock for contended case with very low lock aquisition
> time. The code which I have tested uses PTHREAD_MUTEX_NORMAL, which, on
> Linux,
> will always syscall for the contended case.
> Quite clearly the overhead is with futexes syscalling, because kernel
> resource consumption is 3x higher with the patch than without.
> * With this benchmark, for "half" concurrency in the order of 0.5 x #cores,
> spinlocks still yield better tps, but resource overhead for spinlocks starts
> to take off and futexes are already 40% more efficient, despite the fact
> that
> spinlocks still have a 25% advantage in terms of sps.
> * At "full" concurrency (64 threads on 64 cores), resource consumption of
> the spinlocks leads to almost doubled overall resource consumption and
> the increased efficiency starts to pay off in terms of sps
> * and for the "quadruple overloaded" case (2x128 threads on 64 cores),
> spinlock
> contention really brings the system down and sps drops to half.
These conclusions seem plausible, though I agree we'd want to reproduce
similar behavior elsewhere before acting on the results.
What this seems to me to show, though, is that pthread mutexes are not
fundamentally a better technology than what we have now in spinlocks.
The problem is that the spinlock code is not adapting well to very high
levels of contention. I wonder whether a better and less invasive fix
could be had by playing with the rules for adjustment of
spins_per_delay. Right now, those are coded without any thought about
high-contention cases. In particular I wonder whether we ought to
try to determine which individual locks are high-contention, and behave
differently when trying to acquire those.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
