Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Documentation for dtrace?



On Fri, Sep 09, 2011 at 05:38:11PM -0500, David Young wrote:
> 
> I'd like to put an SDT probe into assembly language.  It looks to
> me like it works differently in NetBSD than in Solaris.  In Solaris,
> the kernel linker ensures that SDT probes are NOPs until activated,
> when they are changed to an illegal instruction (lock nop) that
> causes a #UD trap
> (http://www.cs.dartmouth.edu/~sergey/cs108/dtrace-internals-x86.pdf).
> NetBSD appears to provide SDT probes more simply but possibly with
> higher overhead:

I think this has to do with the order in which the providers were
implemented for NetBSD.  SDT came first, and could be made to work
with almost negligible performance impact by use of the static branch
prediction hint in the macro you quoted.

It's *possible* that the overhead when probes are disabled is lower
for the Sun implementation -- more instructions have to be decoded,
perhaps more space is taken in trace caches (one would hope predicted
false branches are not cached in decoded form, though) etc.  But I
think it should clearly be faster when the probe is enabled, since an
illegal instruction trap will cost much more than a mispredicted
branch.  On the whole I suspect Darran's implementation wins and it
may _always_ win.

Anyway, Darran's implementation didn't grow an instruction-patcher
until I suggested he might be able to use the one from the x86 kernel
startup code to get FBT going quickly.  So it wasn't available as an
option when we needed SDT going "right now".

I suppose for use in assembly code with the present implementation you
would want to reimplement the macro, including the static branch
prediction hint, in asm.

Thor


Home | Main Index | Thread Index | Old Index