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. What do you think ? Rafael -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: output.txt URL: <http://mail.opensolaris.org/pipermail/tesla-dev/attachments/20080404/7ef77ed7/attachment.txt> -------------- next part -------------- A non-text attachment was scrubbed... Name: cycle-wakeups.d Type: text/x-dsrc Size: 929 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/tesla-dev/attachments/20080404/7ef77ed7/attachment.bin>
