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