On Mon, Jul 2, 2012 at 12:20 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
The delay code is stupider than it could be, in that it sleeps without regard to what's happening elsewhere in the system. The futex stuff was interesting to me because it potentially provides a way to sleep "until something interesting happens" rather than "for a fixed amount of time". But it's unclear to me what exactly we'd have to do to squeeze out a win, or even whether it's possible. The other side of this equation, too, is that a decent argument can be made that spinlock contention should be fixed by reducing contention rather than by contending more efficiently. The latter might help get performance from "terrible" up to "poor" in a range of circumstances, but I don't think it's going to get us all the way to "good". -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
