On 2015-01-11 16:47:53 -0500, Robert Haas wrote:
> > My guess that's not so much the overhead of the latch itself, but the
> > lack of the directed wakeup stuff the OS provides for semaphores.
>
> That's possible.
> On Sat, Jan 10, 2015 at 11:35 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> > Interesting. I dimly remembered you mentioning this, that's how I
> > rediscovered this message.
> >
> > Do you remember any details?
>
> No, not really.
I've done a hackish conversion of proc.c to use semaphores and in a
sleeping heavy workload (pgbench -j 390 against a scale 1 db) there
originally was about a %5 regression (fluctuating a fair bit).
I've played with hacking unix_latch.c to
a) use eventfd() for the local latch and (no performance difference anymore)
b) Adding a eventfd to struct Latch for latches that are created from
postmaster. That fd can directly be written to by other processes
(combined slightly faster than semaphores).
Not sure how much b) is acceptable, due to using MaxBackend fds. And
both only help linux.
> > If we could replace all usages of semaphores that set immediate
> > interrupts to ok, we could quite easily make the deadlock detector
> > et. al. run outside of signal handlers. That would imo make it more
> > robust, and easier to understand - right now the correctness of locking
> > done in the deadlock detector isn't obvious. With the infrastructure in
> > place it'd also allow your new parallelism code to run outside of signal
> > handlers.
>
> Yes, I would be very happy to see ImmediateInterruptOK die in a fire.
Yea, I think it's a absolutely horrible idea.
> > Unfortunately currently sempahores can't be unlocked in a signal handler
> > (as sysv semaphores aren't signal safe)... It'd also be not so nice to
> > set both a latch and semaphores in every signal handler.
>
> Agreed.
I've since (re-)realised that we've actually relied on semaphore being
signal safe for years. The PGSemaphoreLock() in proc.c allows
interrupts. And the deadlock detector then uses lwlocks, which in turn
use semaphores. That sucks.
> > Anyway, the discussion since cleared up that we need the self byte to
> > handle a race, anyway.
>
> Eh?
I'm referring to the point Heikki has made in his second paragraph in
5408638C.1080308@vmware.com .
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services