>From "Learning DTrace -- Part 3: Advanced Scripting and Aggregations" http://www.laurustech.com/tech_paper.asp?ID=102
"... DTrace requires that each probe clause produce a fixed-length trace record. This means that the total number of bytes generated by all of the recording actions (trace, printf, etc.), for one clause, must be constant. Each clause can generate a different size record, but one clause must generate the same size record each time it is invoked. If the designers allowed flow control statements, the size of the trace record could vary, depending on whether the if condition was true." Chip > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:dtrace-discuss- > [EMAIL PROTECTED] On Behalf Of Ryan > Sent: Wednesday, October 01, 2008 6:48 AM > To: [email protected] > Subject: [dtrace-discuss] RFE: if/else control flow in probes > > Hi all, > > There's a dead thread about this back at > http://forums.sun.com/thread.jspa?threadID=5075157, but it would be > really nice to have support for if/else control flow in actions. > > Reasons: > 1. The ternary operator ?: is already there (though it doesn't let you > do anything with side effects) > 2. The user can already write arbitrary and expensive non-cacheable > predicates if they want, so performance shouldn't go down as a result. > 3. For performance reasons it would be nice to push expensive non- > cacheable predicates inside the action so the cacheable ones can still > do their job efficiently (see http://docs.sun.com/app/docs/doc/817- > 6223/chp-perf-3?a=view) > > For example, I have a dtrace script that prints out a message whenever > a thread gets preempted during certain (< 1usec long) critical > sections. To avoid the overhead of invoking dtrace every time they > enter/exit (~6usec), at thread startup they pass dtrace a pointer to a > variable which they can then update directly; dtrace checks it during > context switches: > > sched:::off-cpu > / pid == $1 && self->user_ptr != 0 && *(int*) copyin(self->usr_ptr, > sizeof(int)) != 0 / > { > /* print notification message */ > } > > The first two predicates are cacheable and eliminate virtually all of > the threads in the system, while the third predicate is uncacheable and > only required occasionally. To minimize the cost of this probe it would > be very nice to be able to write: > > sched:::off-cpu > / pid == $1 && self->user_ptr != 0 / > { > if( *(int*) copyin(self->usr_ptr, sizeof(int)) != 0) > /* print notification message */ > } > > Alternatively, a smarter compiler might push expensive non-cached > predicates inside the action without exposing any API changes to the > user. That might actually be better because then the user can write > predicates without having to worry quite so much about whether they're > cacheable or not. > -- > This message posted from opensolaris.org > _______________________________________________ > dtrace-discuss mailing list > [email protected] _______________________________________________ dtrace-discuss mailing list [email protected]
