Rafael Vanoni wrote: > Eric Saxe wrote: >> [snip] >>> >> I guess there's two ways of looking at this: >> A) PowerTOP is reporting on the events that are causing CPUs to wake up. >> B) PowerTOP is reporting on the events that are (or can) cause CPUs to >> wake up. >> >> Perhaps one could be the default behavior, and the other could be >> enabled with an option. My impression is that A is the default that >> folks would expect, but I think B is useful. I think B is the way the >> tool works now. >> >> To get A, I think PowerTOP needs "D" code that is able to correlate >> firing of the cyclic-fire probe with a firing of the >> idle-state-transition, and reports only the cyclic-firing that >> actually caused the CPU to wake up. > > Ok, I modified the D script that events.c uses (cyclic-wakeups.d). > I believe it does what Eric is suggesting, but not with the desired > output (output.txt). It only reports cyclic events that generate an idle > to active state transition. I'm not sure that's what we want. > > I ran some tests and the timestamp for the firing of unix`cbe_hres_tick, > genunix`clock and genunix`cyclic_timer are extremely close to each > other. I'm running some tests that set a granularity for observing > activity. It fixes our current problem and could eventually be used as a > feature.
Ok, that turned out to be a bad idea ;) I changed the dtrace script on events.c (attached) so that clock activity would only take unix`cbe_hres_tick into account, ignoring genunix`clock and genunix`cyclic_timer. I'm assuming that unix`cbe will always fire first - not sure if that's correct. However, the aggregate cpu wakeups still don't add up correctly. I'm looking into that now. Rafael -------------- next part -------------- A non-text attachment was scrubbed... Name: events-cbe-only.d Type: text/x-dsrc Size: 1295 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/tesla-dev/attachments/20080404/81d74034/attachment.bin>
