[dtrace-discuss] DTrace under Linux
陶捷 (Euler Tao)
eulertao at gmail.com
Wed Feb 14 04:01:19 PST 2007
I've read the dtrace usenix paper already.
At the end of this paper, the authors said that one of the future work was
the "performance counters".
Has this been implemented in the current DTrace?
Regards
T.J.
2007/2/14, Sean McGrath - Sun Microsystems Ireland <sean.mcgrath at sun.com>:
>
> ???? (Euler Tao) stated:
> < Thanks, I understand now.
> <
> < er... I've planed to read the source code of DTrace. I think it may be
> < consisted of two parts, the kernel of Dtrace and the 30K+ providers.
> < And is the main code of DTrace in a separate directory in the whole
> kernel
> < code tarball, e.g. on-src-b56.tar.bz2.
> < I've searched the key word, "dtrace", in the web page,
> < http://cvs.opensolaris.org/source/.
> < And I was confused by the results. They looked a little disordered.
>
> Dtrace may look 'disordered'. You're probably finding all the
> dtrace probes points etc that are scattered all over the place in various
> modules, libraries etc. The bits that really make up the dtrace
> framework
> are better explained from Bryan's blog, below.
>
> <
> < I have no experience on reading any Solaris's Codes yet.
> < Can someone do me a favor? Give me some hints.
>
> Dtrace was the original bit of code that was opened up before the full
> opensolaris, way back. Bryan's blog gives us a tour of the dtrace code
> from this initial code:
>
> http://blogs.sun.com/bmc/date/20050125
>
> Its still good to go through this once in a while.
>
> That along with the dtrace usenix paper gives a good overview of how
> dtrace works along with where it lives in opensolaris.
>
> http://www.sun.com/bigadmin/content/dtrace/dtrace_usenix.pdf
>
> That should help you get started :)
>
> Sean.
> .
> <
> < Thanks!
> <
> < Regards
> <
> < T.J.
> <
> <
> < 2007/2/14, Casper.Dik at sun.com <Casper.Dik at sun.com>:
> < >
> < >
> < >>Why do you say that SystemTap only is done on i386?
> < >>Does it means that, compared with DTrace, SystemTap is focused more on
> < >>hardware infomation?
> < >
> < >Dynamic kernel probing tools like DTrace need to understand and modify
> < >the instruction streams in the kernel.
> < >
> < >>Does DTrace has two different kernel parts?
> < >>I means for the x86 and SPARC architecture, there're something
> different
> < >>inside the 2 DTraces?
> < >
> < >Yes; DTrace is atypical in that it requires quite intimate knowledge
> < >of how instruction streams work. But from a user's perspective this
> < >is all hidden and you can use the same scripts on both architecture.
> < >
> < >The DTrace architecture limits the knowledge of the processor
> architecture
> < >to the DTrace to the providers which need that knowledge (such as the
> < >fbt and fasttrap provider)
> < >
> < >Sun has a requirement for "completeness", i.e., support for all
> < >architectures,
> < >when putting a project in Solaris. That's why we have support for
> DTrace
> < >on all supported platforms.
> < >
> < >In Linux, it is possible that systemtap becomes mainstream without
> support
> < >for other architectures. (Systemtap is also much more limited and does
> < >not
> < >make the safety guarantees DTrace makes)
> < >
> < >Casper
> < >
>
> < _______________________________________________
> < dtrace-discuss mailing list
> < dtrace-discuss at opensolaris.org
>
>
> --
> Sean.
> .
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20070214/cbb165ec/attachment-0001.html
More information about the dtrace-discuss
mailing list