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. :)
> 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. There's 3 cyclics or so that fire 100 times a second. The cyclic subsystem is batching them, so with this change you see that one that caused the CPU to wake up..but you don't see the firings of the other ones that the cyclic subsystem processed at the same time. > What do you think ? :) That's why I like the option of both modes. Thanks, -Eric > Rafael > > ------------------------------------------------------------------------ > > _______________________________________________ > tesla-dev mailing list > tesla-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/tesla-dev
