|
Thanks for implementing this feature. A few comments simply on the
presentation of the ideas. 1) Section 2 talks about args[0] and args[1], yet the examples use arg0 and arg1. This may be just cosmetic, but it might be worth being consistent. Also, should the description be specific about what data type is given for args[0] and args[1], or is that implicit by saying they are program counter values? 2) Example 3 (and hence 4) sounds unclear to me given the discussion last week. It still leaves open the interpretation that all the L2 cache misses that are being counted are all caused by the executable "brendan". Given the discussion last week, it would be more clear to describe it being a sampling of what the brendan executable was doing each time the L2 cache miss counter hit the target. It might be useful to add a second clause to the example 3 script to count events that happened when some other executable was executing. This makes the "brendan" counts a more effective drill-down into the total set of L2 cache miss events. Did I understand last week's discussion correctly? cpc:::BU_fill_req_missed_L2-all-0x7-10000
/execname == "brendan"/
{
@[ufunc(arg1)] = count();
cpc:::BU_fill_req_missed_L2-all-0x7-10000
/execname != "brendan"/
{
@["OtherExecutable"] = count();
}
}
3) It might also be helpful to have an example that keeps a running total of some performance counter, and then periodically samples that counter during some other event of interest. I.e. we could use the dtrace tools to keep a running count of L2 cache misses, and then wake up each several msec and sample both who is running and what the current counts are. (In such an application, we would just be using dtrace as a quick way of enabling and disabling the specific counters we want to track.) Peter Jon Haslam wrote: Tracing Fans, |
_______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
