Re: [PATCH] dtrace probes for memory manager - Mailing list pgsql-hackers

From Frank Ch. Eigler
Subject Re: [PATCH] dtrace probes for memory manager
Date
Msg-id 20091210213440.GB32064@redhat.com
Whole thread Raw
In response to Re: [PATCH] dtrace probes for memory manager  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
List 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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Adding support for SE-Linux security
Next
From: Tom Lane
Date:
Subject: Re: Adding support for SE-Linux security