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
> Thanks,
> -Aubrey
>
