On Wed, Apr 06, 2011 at 06:21:30PM +0200, Manuel Bouyer wrote: > > Maybe I don't understand how dtrace works then, but I though installed/started > it generates a continous flow of events which are monitored, which have > to be retrieved from userland. Isn't it how this works ?
No. The basic unit of measurement in DTrace is a "probe". Probes can be statically placed in the source code with SDT_PROBE() or dynamically "placed" in the object code by automatic binary patch (the "FBT" provider). Every DTrace script refers to a particular set of probes. When the script is started (using the userspace "dtrace" program) only the specified probes are actually turned on -- so only data for those probes is generated. With the automatic "FBT" provider, the granularity is the function call boundary. So for a given function call or calls, you can generate data that can be walked by the D script -- the function's arguments, for example, which can be examined by the script *with their data types*: you can walk structures, etc. There are even convenience functions for counting the values of variables, accumulating histograms, etc. The FBT probes are binary-patched into place on the function entry and exit so they have no cost at all when not enabled. With the "SDT" provider, where probes are placed by hand in the source code, you can get much finer-grained control -- down to the individual line of source code. You can also export local variables, etc. whereas FBT gives you only the ones actually passed to or returned from the function as a whole. Both are very useful; neither is expensive when not turned on. It is easier to get SDT working on a new architecture than FBT, because you don't have to get the binary-patch mechanism working. Solaris has a basic set of SDT providers that include system calls, memory allocation, the device driver interface, various points in the network stack, etc.. This is the way I personally think we should go for general purpose diagnostic and debug facilities in the kernel. But FBT is just fantastic for debugging misbehaving code in unexpected areas of the kernel. Including code it never occurred to anyone to instrument before. It's an incredible tool. In an ideal world, on all major architectures we would have both. -- Thor Lancelot Simon [email protected] And now he couldn't remember when this passion had flown, leaving him so foolish and bewildered and astray: can any man? William Styron
