On Tue, Jan 19, 2010 at 12:52:53AM +0000, Robert Milkowski wrote:
> Hi,
>
> It might be interesting to some of you.
>
> http://int3.de/download/ntrace/NTrace_FunctionBoundaryTracingForIa32.pdf
> http://int3.de/download/ntrace/NTrace_FunctionBoundaryTracingForIa32_WCRE2009_SlideDeck.pdf
>
> I repeated the getpid() microbenchmark on my Toshiba r600 and I got
> about 4x slowdown while fbt::getpid:entry,fbt::getpid:return were active
> and about 2x slowdown for syscall::getpid:entry,syscall::getpid:return
> so the numbers they provided for x86 seem right. I noticed that they
> used open solaris 32bit for some reason, I did in 64bit mode and got
> similar results so probably doesn't matter that much for that particular
> microbenchmark.
>
> Of course in real life it doesn't matter that much and real overhead
> will be much smaller in most cases still the ntrace results are interesting.
They seem to be lauding themselves for simply intelligently using a
framework put together by Microsoft. In particular, the compiler has
graciously created an instruction signature and (more importantly) trampoline
padding between functions -- allowing them to safely use branch-based
(instead of trap-based) instrumentation. They seem to conveniently forget
this essential bit of compiler help when discussing the trap-based
instrumentation of KernInst and DTrace...
More generally, this paper (like many pre-DTrace instrumentation papers)
obsesses over instrumentation overhead while ignoring the more significant
issues of disabled probe effect and efficient data processing (scalable
aggregations, wait-free dynamic variables, predicate caching, etc).
The first issue is presumably immaterial: even if this technique has
disabled probe effect, that decision has already been made by Microsoft.
But the second issue remains paramount: who cares about the overhead of
instrumenting millions of getpid calls per second if you can't aggregate
that information in a scalable fashion?
All of that said, I'm flattered to see them refer to "function boundary
tracing" as if it's a notion that existed prior to DTrace, as that term
is one that I vividly recall pulling out of my ass... ;)
- Bryan
--------------------------------------------------------------------------
Bryan Cantrill, Sun Microsystems Fishworks. http://blogs.sun.com/bmc
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
