Re: Latch implementation
От | Heikki Linnakangas |
---|---|
Тема | Re: Latch implementation |
Дата | |
Msg-id | 4C9B5C62.9010404@enterprisedb.com обсуждение исходный текст |
Ответ на | Latch implementation (Ganesh Venkitachalam-1 <ganesh@vmware.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: