On Thursday, November 15, 2007 9:05 PM, Bill.Holler at Sun.COM wrote:
> Eric Saxe wrote:
>> Li, Aubrey wrote:
>>
>>> On Friday, November 16, 2007 9:25 AM, Eric Saxe wrote:
>>>
>>>
>>>
>>>> Li, Aubrey wrote:
>>>>
>>>>
>>>>> Sorry, I didn't catch your point. We have only one probe, from
>>>>> which we only have a timestamp. Next time the probe fired, the
>>>>> key of the association is changed. How to track an interval
>>>>> between the first time and the second time of the association
>>>>> with the same key?
>>>>>
>>>>>
>>>>>
>>>> I guess you need to track the old state and time for the CPU. I
>>>> think you can do that in some associative arrays:
>>>>
>>>>
>>>>
>>>>>> cpu_change_speed
>>>>>>
>>>>>>
>>>> {
>>>> ...
>>>> this->cpu = (processorid_t)arg1; /* arg1 == CPU
>>>> for which we
>>>> are changing speed */
>>>> this->newspd = (uint_t)arg2; /* arg2 == New speed
>>>> */
>>>>
>>>> this->oldspd = current_speeds[this->cpu];
>>>> current_speeds[this->cpu] = this->newspd;
>>>>
>>>> this->now = timestamp;
>>>> time_at_speed = this->now - state_times[this->cpu];
>>>> state_times[this->cpu] = this->now;
>>>>
>>>> @pstate_times[this->oldspd, this->cpu] = sum(time_at_speed); }
>>>>
>>>> ... or to get aggregate times (across all CPUs) I think you should
>>>> be able to do:
>>>>
>>>> @pstate_times[this->oldspd] = sum(time_at_speed);
>>>>
>>>>
>>>>
>>> Eric,
>>>
>>> This is almost I have tried. The result is unsatisfied for me.
>>> As you know, P-state switching frequency is low.
>>> So,
>>>
>>> 1) from time to time, P-state only switches one time in the
>>> sampling period, you'll get nothing. This->oldspd = 0
>>>
>>> 2) as I said, we have only one probe.
>>> The first time_at_speed is always wrong and we don't know the
>>> initial timestamp we should subtract.
>>>
>>>
>> 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. :)
>>
>> -Eric
>>
>>
> Don't know if it helps, but the cpu_info kstat has a
> "current_clock_Hz" entry
> that will tell you what frequency a cpu is currently running.
Yes, it does. We must use this member to query the current state. ;-)
Thanks,
-Aubrey
