Horton

Re: kqueue

Matteo Beccati <php@beccati.com>

View thread View on postgr.es
From: Matteo Beccati <php@beccati.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Thomas Munro <thomas.munro@enterprisedb.com>, Marko Tiikkaja <marko@joh.to>, Alvaro Herrera <alvherre@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>, Noah Misch <noah@leadboat.com>
Date: 2016-09-14T13:09:59Z
Lists: pgsql-hackers 
Hi,

On 14/09/2016 00:06, Tom Lane wrote:
> I'm inclined to think the kqueue patch is worth applying just on the
> grounds that it makes things better on OS X and doesn't seem to hurt
> on FreeBSD.  Whether anyone would ever get to the point of seeing
> intra-kernel contention on these platforms is hard to predict, but
> we'd be ahead of the curve if so.
>
> It would be good for someone else to reproduce my results though.
> For one thing, 5%-ish is not that far above the noise level; maybe
> what I'm measuring here is just good luck from relocation of critical
> loops into more cache-line-friendly locations.

FWIW, I've tested HEAD vs patch on a 2-cpu low end NetBSD 7.0 i386 machine.

HEAD: 1890/1935/1889 tps
kqueue: 1905/1957/1932 tps

no weird surprises, and basically no differences either.


Cheers
-- 
Matteo Beccati

Development & Consulting - http://www.beccati.com/

Commits

  1. Add kqueue(2) support to the WaitEventSet API.

  2. Add WL_EXIT_ON_PM_DEATH pseudo-event.

  3. Be conservative about alignment requirements of struct epoll_event.

  4. Make idle backends exit if the postmaster dies.