Michael,
Thank you for your attention.
Michael Shapiro wrote On 11/21/05 15:39,:>>It''s not possible to disable probes dynamically and that
functionality would
>>run rather contrary to the current design. Sorry, but I don''t
this will
>>probably be coming any time soon.
>>
>>Adam
>
>
> In addition to what Adam said, it might be worth explaining at a higher
> level what problem you are trying to solve, which might help us think
> of something else. i.e. *why* is it vital that you turn things off
> within the running D program as opposed to starting a new one which
> is more optimal given the results of the first program? DTrace''s
design
> center is to allow you to iterate rapidly on analyzing the system by
> instrumenting, learning, and re-instrumenting.
I am currently developing a tool called Qtrace which allows users to
trace entry/return/call coverages of both userland and kerneland
modules. The nature of this tool requires to turn on all entry/return
probes of the traced modules. If user only need coverage and don''t
care about hit count of entry/return/call, then we only need to trace
each of them once. This way, we can reduce tracing performance impact.
Our current implementation allows user to select tracing limit such as
1, 10, ... or up to 10000000 or No Limit. So, in the case of selecting
10, the predicate /entered[id, caller] <= 10/ and action
entered[id, caller]++ become part of function entry probe. The scheme
works but in the case of short functions being called billions of times
the Dtrace trap overhead is still significant. We already thought
about your suggested alternative but it is only practical if the module
doesn''t have many functions such as less than 100. If the traced
module has thousands of functions, then we need to be able to exclude
those functions that reach tracing limit. But using the current
globbing pattern matching scheme employed by Dtrace to exclude patterns
becomes almost like solving puzzles. For example, to exclude single
pattern "abc" we can construct probe as below:
pid$1:xyz:?:entry,
pid$1:xyz:??:entry,
pid$1:xyz:[!a]??:entry,
pid$1:xyz:?[!b]?:entry,
pid$1:xyz:??[!c]:entry,
pid$1:xyz:????*:entry
But to exclude multiple patterns such as "abc" and "defg",
it becomes
too complicated. Besides, to reconstruct a new set of probes, requires
to stop the pid of user application, start dtrace, restart stopped pid.
All of these activities introduce new overheads to overall automatic
process in Qtrace.
Now you can see why we like to be able to turn off probe dynamically.
If you have a good alternative, we like to hear it.
BTW, you can visit http://mm-188/ to see how Qtrace works. If you like
to know the internal of Qtrace, I can provide you more informations.
THX
> -Mike
>
> --
> Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
--
************************************************
* C P Lin, Common Technology Project Lead. *
* Sun Microsystems Inc. *
* E-Mail: c.lin at sun.com *
* Address: 4150 Network Circle, M/S UMPK12-330 *
* Santa Clara, CA 95054 *
* Phone: 650/352-4967 Fax: 650/786-7816 *
************************************************