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.
Bill
>> Thanks,
>> -Aubrey
>>
>>
>
> _______________________________________________
> tesla-dev mailing list
> tesla-dev at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/tesla-dev
>
