On Sat, Oct 10, 2009 at 07:56:14AM -0700, Martin Cerveny wrote: > PS: I understand that there is the error in PCFS (I will probably find > and correct the problem), but I am very disappointed by "dtracing side > effect" !!!! This breaks non intrusiveness of dtrace.
All DTrace did here was have some enabled-probe performance impact, which is what it normally does and unavoidable. The fact that there is a race condition which can be triggered by that performance impact is a bug, not in DTrace, but in the affected sub-system (pcfs). The fact that DTrace can have such impact is sometimes a very useful side-effect of DTrace, and it's why there's a chill() [destructive] function that you can use in probe actions: race conditions can be very difficult to trigger, making the ability to play with timing via DTrace very useful. Also, as others have pointed out, you enabled all FBT probes; when you do that the per-enabled-probe performance impact of DTrace adds up quickly. You might argue that enabling too many probes is itself as destructive as chill(), but unlike chill(), DTrace cannot judge the overall performance impact of your D scripts; failing to distinguish between destructive and non-destructive actions on the argument that all performance impact of enabled probes, no matter how tiny, is destructive would make it harder to use DTrace safely, not easier. Nico -- _______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
