Re: Latch implementation

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Ganesh Venkitachalam-1 <ganesh(at)vmware(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Latch implementation
Date: 2010-09-23 13:55:46
Message-ID: 4C9B5C62.9010404@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2010-09-23 13:56:38 Re: Latch implementation
Previous Message Bruce Momjian 2010-09-23 13:55:43 Re: Git cvsserver serious issue