Eric Saxe 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 think that's the correct implication of the change. With this > behavior, the tool is showing you exactly what events caused CPU > wakeups....of course the downside of this is you can't see by running > the tool in this mode what *all* you need to fix to get the system to be > power efficient...you only get to see the first cyclic...since the other > firings are processed opportunistically during the processing of the > first one. :)
Ok.. now I understand why you proposed B :) However, if we extend B to every type of activity, the tool will report nothing except transitions. Maybe a more accurate definition of the operating states could be A) PowerTOP is reporting events that cause CPU activity B) PowerTOP is reporting events that cause CPU activity but only cyclic events that cause processor state changes I think "wake up" is a bit misleading, as it has a connotation of state transition - which is not always the case. "Activity" seems better to me. How does that sound ? We could also have options for reporting only user or only kernel events. thanks Rafael
