Hi Aubrey, Li, Aubrey wrote: >> Yea, so the DTrace probe will only fire when a pstate transition >> happens...we need a way to query the current CPU P-states so we know >> what state we are in should the probe not fire at all during the >> sampling period. :) >> >> > > 1) probe not fire. > - We can query the current state from kstat. "current_clock_Hz" in > the module "cpu_info" contains the speed. > Agreed.
> 2) probe fire only one time. > - we know the timestamp of the switching, but we don't know when it > is in the sampling period. > So we are not able to get how long P1 stays and how long P2 does. > How about we take an initial timestamp when the sampling period begins. If the probe doesn't fire, then we would report being in the state we read out of the kstat 100%. If it fires once during the sampling period, then we'll report how much time was spent in each of the two pstates during the sample period, etc. > 3) probe fire two times or more > - we are lost to calculate the data of the first p-state and the last > p-state. > I think we could take the same approach as above... > Is the rule that we should not touch the kernel as possible as we can? > If we can use interfaces that are already in place, I think that would be preferable...but if a suitable interface doesn't exist we can certainly add one... Thanks, -Eric
