Re: Latch implementation
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Ganesh Venkitachalam-1 <ganesh@vmware.com>
Cc: pgsql-hackers@postgresql.org
Date: 2010-09-23T13:55:46Z
Lists: pgsql-hackers
On 22/09/10 23:31, Ganesh Venkitachalam-1 wrote: > I've been playing around with measuring the latch implementation in 9.1, > and here are the results of a ping-pong test with 2 processes signalling > and waiting on the latch. I did three variations (linux 2.6.18, nehalem > processor). > > One is the current one. > > The second is built on native semaphors on linux. This one cannot > implement WaitLatchOrSocket, there's no select involved. > > The third is an implementation based on pipe() and poll. Note: in its > current incarnation it's essentially a hack to measure performance, it's > not usable in postgres, this assumes all latches are created before any > process is forked. We'd need to use mkfifo to sort that out if we really > want to go this route, or similar. > > - Current implementation: 1 pingpong is avg 15 usecs > - Pipe+poll: 9 usecs > - Semaphore: 6 usecs > > The test program & modified unix_latch.c is attached, you can compile it > like "gcc -DPIPE -O2 sema.c" or "gcc -DLINUX_SEM -O2 sema.c" or "gcc -O2 > sema.c". Interesting, thanks for the testing! Could you also test how much faster the current implementation gets by just replacing select() with poll()? That should shave off some overhead. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com