On Sun, May 13, 2018 at 8:40 AM, Peter Geoghegan <p...@bowt.ie> wrote: > On Fri, May 11, 2018 at 11:46 PM, Christoph Berg <m...@debian.org> wrote: >> Re: Peter Geoghegan 2018-05-12 >> <CAH2-WznHEfw6jJiyH8mBLPT=vkclyofwjxeqchidckdnv72...@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
