Li, Aubrey wrote: > Rafael.Vanoni wrote: > >> Here's an exported changeset for these changes. A few changes >> on this one.. >> >> Because xc_common and init_mondo are platform specific DTrace >> probes, I >> had to create a new file (dtp_events.c) per platform folder. This new >> file contains the scripts for the event reports. For clarity sake, I >> moved the common source files to a new folder 'common' and updated >> the Makefiles accordingly. >> >> fbt::send_dirint (and its SPARC counterpart) fire for events >> which we're >> not necessarily interested, cyclics for instance. So I need to >> look into >> that and see what can be done for the --cpu option. This changeset is >> basically looking at sysinfo:::xcalls, but noting the function >> whenever possible through xc_common. I don't see another way of >> catching the routine responsible for the xcall at this time. >> >> I tested this patch on an idle two quad core Xeon and the amount of >> xcalls matched the current ptop version. >> >> Let me know what you think. >> > > Here is what I got: > =========================================== > Wakeups-from-idle per second: 1987.5 interval: 5.0s > Top causes for wakeups: > 57.7% (1147.7) sched :<cross call> > > 9.6% (191.3) sched :<cross call> unix`dtrace_xcall_func > > ----snip---- > 0.2% ( 3.2) powertop :<cross call> > > ----snip---- > =========================================== > Any idea why we need to report > 1) "57.7% (1147.7) sched :<cross call>" > and > 2) "9.6% (191.3) sched :<cross call> unix`dtrace_xcall_func"? > > Does 1) contain 2)? > > Okay, this probably can help us to understand our goal. > we know 1147 times cross call from "sched", but we only know 191 times > cross call from the function "dtrace_xcall_func", where the others come from? > That is what we want to know. > > Any throughts?
The problem was that the xcalls probe fires N times within xc_common, and the script was zeroing the variable with the address of the xcall function after the first one. This export contains all the changes from the previous with this issue fixed. Let me know what you think. Thanks, Rafael -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 7770.exp URL: <http://mail.opensolaris.org/pipermail/tesla-dev/attachments/20081219/1cde74c3/attachment.ksh>
