Re: extent-patch and overview of what is supposed to follow

[Thor Lancelot Simon <tls%panix.com@localhost>]

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                                              
tls%panix.com@localhost
    And now he couldn't remember when this passion had flown, leaving him so
  foolish and bewildered and astray: can any man?
                                                   William Styron