Re: Compiler warnings with --enable-dtrace

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Christoph Berg <myon(at)debian(dot)org>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Compiler warnings with --enable-dtrace
Date: 2018-05-12 20:40:25
Message-ID: CAH2-Wz=n=M0_6X46qoLjgf2ADU0x0etM1yjbG8TYMcwHeRxjkw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, May 11, 2018 at 11:46 PM, Christoph Berg <myon(at)debian(dot)org> wrote:
> Re: Peter Geoghegan 2018-05-12 <CAH2-WznHEfw6jJiyH8mBLPT=VKcLyOfwjXEQCHidCkDNv72PSA(at)mail(dot)gmail(dot)com>
>> It seems to be surprisingly low overhead in many cases.
>
> I was pondering adding --enable-dtrace in the Debian packages, but
> Andres advised against it, "because it affects code generation".
>
> So far, perf seems to be the tool of choice.

Even perf has support for USDT probes from kernel 4.8 on, as the
article mentions. BCC isn't something that you can install just as
easily as perf at the moment, but I think that that's just a matter of
time. As you probably know, BCC can do quite a lot of interesting
things that perf cannot. It deserves to become very popular, and there
are already a lot of early adopters. If this sounds improbable to
anyone, then they should consider that there are already cute comics
about USDT probes that are quite popular [1]. The unnecessarily
complicated way in which BCC/eBPF is distributed and integrated with
the kernel doesn't seem to be holding it back too much.

Does Debian take any position on what packagers should do with USDT
probes in general?

I don't think that this should be an urgent issue for you. I expect it
to become important in the next couple of years, though.

[1] https://jvns.ca/blog/2017/07/05/linux-tracing-systems/#zine
--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-05-12 21:25:05 Re: lazy detoasting
Previous Message Peter Geoghegan 2018-05-12 20:22:55 Re: Postgres 11 release notes