Re: sinval synchronization considered harmful - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: sinval synchronization considered harmful
Date
Msg-id 4E280A8C020000250003F661@gw.wicourts.gov
Whole thread Raw
In response to sinval synchronization considered harmful  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: sinval synchronization considered harmful
List pgsql-hackers
Robert Haas  wrote:
> SIGetDataEntries(). I believe we need to bite the bullet and
> rewrite this using a lock-free algorithm, using memory barriers on
> processors with weak memory ordering.
> [32 processors; 80 clients]
> On unpatched master
> tps = 132518.586371 (including connections establishing)
> tps = 130968.749747 (including connections establishing)
> tps = 132574.338942 (including connections establishing)
> With the lazy vxid locks patch
> tps = 119215.958372 (including connections establishing)
> tps = 113056.859871 (including connections establishing)
> tps = 160562.770998 (including connections establishing)
> gets rid of SInvalReadLock and instead gives each backend its own
> spinlock.
> tps = 167392.042393 (including connections establishing)
> tps = 171336.145020 (including connections establishing)
> tps = 170500.529303 (including connections establishing)
> SIGetDataEntries() can pretty easily be made lock-free.
> tps = 203256.701227 (including connections establishing)
> tps = 190637.957571 (including connections establishing)
> tps = 190228.617178 (including connections establishing)
> Thoughts? Comments? Ideas?
Very impressive!  Those numbers definitely justify some #ifdef code
to provide alternatives for weak memory ordering machines versus
others.  With the number of CPUs climbing as it is, this is very
important work!
-Kevin


pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: fixing PQsetvalue()
Next
From: Robert Haas
Date:
Subject: Re: Single pass vacuum - take 1