On Sun, May 13, 2018 at 8:40 AM, Peter Geoghegan <pg@bowt.ie> wrote:
> On Fri, May 11, 2018 at 11:46 PM, Christoph Berg <myon@debian.org> wrote:
>> Re: Peter Geoghegan 2018-05-12 <CAH2-WznHEfw6jJiyH8mBLPT=VKcLyOfwjXEQCHidCkDNv72PSA@mail.gmail.com>
>>> It seems to be surprisingly low overhead in many cases.
>>
>> I was pondering adding --enable-dtrace in the Debian packages, but
I was initially confused about how --enable-dtrace was being used to
build USDT probes on Linux. I see that's because systemtap-std-dev
installs its own fake /usr/bin/dtrace that understands the same
switches. Huh.
>> Andres advised against it, "because it affects code generation".
Right, it inserts a bunch of NOPs and may cause nearby code to be
rearranged slightly. It'd be interesting to know if it actually makes
any difference to performance, considering the current set of probe
locations. Whether they're useful for analysing production systems,
I'm not sure anyway -- when I've worked with (real) dtrace I've
typically been adding throwaway probes of my own for testing patches.
I think it's a pretty interesting technique for investigating parallel
query efficiency, for things that simple user stack sampling can't
tell you.
> [1] https://jvns.ca/blog/2017/07/05/linux-tracing-systems/#zine
Thanks. I do love all this introspection and dynamic tracing tech,
but wow, it's like a bowl of alphabet soup on Linux at this point.
--
Thomas Munro
http://www.enterprisedb.com