On Sep27, 2013, at 00:55 , Andres Freund <and...@2ndquadrant.com> wrote:
> So the goal is to have LWLockAcquire(LW_SHARED) never block unless
> somebody else holds an exclusive lock. To produce enough appetite for
> reading the rest of the long mail, here's some numbers on a
> pgbench -j 90 -c 90 -T 60 -S (-i -s 10) on a 4xE5-4620
>
> master + padding: tps = 146904.451764
> master + padding + lwlock: tps = 590445.927065
>
> That's rougly 400%.
Interesting. I played with pretty much the same idea two years or so ago.
At the time, I compared a few different LWLock implementations. Those
were AFAIR
A) Vanilla LWLocks
B) A + an atomic-increment fast path, very similar to your proposal
C) B but with a partitioned atomic-increment counter to further
reduce cache-line contention
D) A with the spinlock-based queue replaced by a lockless queue
At the time, the improvements seemed to be negligible - they looked great
in synthetic benchmarks of just the locking code, but didn't translate
to improved TPS numbers. Though I think the only version that ever got
tested on more than a handful of cores was C…
My (rather hacked together) benchmarking code can be found here:
https://github.com/fgp/lockbench.
The different LWLock implementations live in the various pg_lwlock_* subfolders.
Here's a pointer into the relevant thread:
http://www.postgresql.org/message-id/651002c1-2ec1-4731-9b29-99217cb36...@phlo.org
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
