Re: Switch to unnamed POSIX semaphores as our preferred sema code?

I wrote:
> Although in normal cases the semaphore code paths aren't very heavily
> exercised in our code, I was able to get a measurable performance
> difference by building with --disable-spinlocks, so that spinlocks are
> emulated with semaphores. On an 8-core RHEL6 machine, "pgbench -S -c 20
> -j 20" seems to be about 4% faster with unnamed semaphores than SysV
> semaphores. It'd be good to replicate that test on some higher-end
> hardware, but provisionally I'd say unnamed semaphores are faster.

I realized that the above test is probably bogus, or at least not very
relevant to real-world Postgres performance. A key performance aspect of
Linux futexes is that uncontended lock acquisitions, as well as releases
that don't need to wake anyone, don't enter the kernel at all. However,
in PG's normal use of semaphores, neither scenario occurs very often;
processes lock their semaphores only after determining that they need to
wait, and release semaphores only when it's known they'll waken a sleeper.
The futex fast-path cases can occur only in the race condition that
someone else awakens a would-be waiter before it actually reaches its
semop call. However, uncontended locks and releases *are* very common
for spinlocks. This means that testing with --disable-spinlocks will show
a futex performance benefit that's totally irrelevant for real cases.

Based on that analysis, I abandoned testing with --disable-spinlocks
and instead tried to measure the actual speed of contended heavyweight
lock acquisition/release. I used
pgbench -f lockscript.sql -c 20 -j 20 -T 60 bench
with the script being
begin; lock table pgbench_accounts; commit;
I got speeds between 10500 and 10800 TPS with either semaphore API;
if there's any difference at all, it's below the noise level for
this test scenario.

So I'm now thinking there's basically no performance consideration
here, and the point of switching would just be to get out from
under SysV kernel resource limits. (Again though, this applies
only to Linux --- the other thread I cited suggests things might
be quite different on FreeBSD for instance.)

Can anyone think of a test case that would stress semaphore operations
more heavily, without being unrealistic?

regards, tom lane