In DTrace, the primary mechanism for filtering out uninteresting events is the predicate mechanism, which is described in more detail in Section 2.1, “D Program Structure”. Predicates are useful when you know whether a probe event is of interest at the time that it fires. For example, if you are only interested in activity that is associated with a certain process or a certain file descriptor, you know when the probe fires if it is associated with the process or file descriptor of interest. Note that in other situations, you might not know whether a given probe event is of interest until some time after the probe fires.
Take the example of a system call that is occasionally failing
with a common error code such as EIO
or
EINVAL
. In this instance, you might want to
examine the code path leading to the error condition. To capture
the code path, you could enable every probe, but only if the
failing call can be isolated in such a way that a meaningful
predicate can be constructed. If the failures are sporadic or
non-deterministic, you would be forced to trace all of the events
that might be interesting, then later post-process the data to
filter out the events that were not associated with the failing
code path. In this case, even though the number of interesting
events might be reasonably small, the number of events that must
be traced is very large, making post-processing difficult.
In such situations, you can use speculative tracing facility to tentatively trace data at one or more probe locations. You can then decide to commit the data to the principal buffer at another probe location. The result is that your trace data only contains the output that is of interest; no post-processing is required and the DTrace overhead is minimized.