Rafael Vanoni wrote: > 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. Why? With your change the only reason those aren't showing up, is probably because they weren't the cyclic firing responsible for waking up the CPU.
> I'm assuming that unix`cbe will always fire first - not sure if that's > correct. I don't think that's necessarily true. When a cyclic fires, the cyclic subsystem checks to see if other cyclics are due about the same time..and will process them as well. It may well be chance which one is lucky enough to be at the front of the line. > However, the aggregate cpu wakeups still don't add up correctly. I'm > looking into that now. Thanks, -Eric
