On Sep27, 2013, at 00:55 , Andres Freund <andres@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-incrementcounter to further reduce cache-line contention D) A with the spinlock-based queue replaced by a
locklessqueue
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-99217CB36653@phlo.org
best regards,
Florian Pflug