From: | "Frank Ch(dot) Eigler" <fche(at)redhat(dot)com> |
---|---|
To: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> |
Cc: | Bernd Helmle <mailings(at)oopsware(dot)de>, Greg Smith <greg(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] dtrace probes for memory manager |
Date: | 2009-12-10 21:34:40 |
Message-ID: | 20091210213440.GB32064@redhat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi -
On Thu, Dec 10, 2009 at 09:33:28PM +0100, Zdenek Kotala wrote:
> [...]
> > If the dormant overhead of these probes is measured or suspected to be
> > excessive, consider using the dtrace-generated per-probe foo_ENABLED()
> > conditional, or a postgres configuration global thusly:
> [...] foo_enable() is good to use when number of argument and their
> evaluation cost too much. In this case it does no seem to be much
> useful. [...]
Right, I just wanted to make the others aware of the option.
> > if (__builtin_expect(TRACE_POSTGRESQL_MCXT_ALLOC_ENABLED(), 0))
> > TRACE_POSTGRESQL_MCXT_ALLOC(...);
> >
> > so that the whole instrumentation parameter setup/call can be placed
> > out of the hot line with gcc -freorder-blocks.
>
> compiler specific construct is not good way. Do not forget that also
> other compiler exists.
Certainly. Many projects -- but apparently not postgresql -- wrap
such branch prediction hints in macros such as likely() and
unlikely(), which are easily no-op'd for compilers that don't support
this sort of thing.
- FChE
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2009-12-10 21:56:59 | Re: 8.4.1 ubuntu karmic slow createdb |
Previous Message | Robert Haas | 2009-12-10 21:26:48 | Re: Adding support for SE-Linux security |