On Friday, November 16, 2007 10:52 AM, 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. :)
>
1) probe not fire.
- We can query the current state from kstat. "current_clock_Hz" in
the module "cpu_info" contains the speed.
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.
3) probe fire two times or more
- we are lost to calculate the data of the first p-state and the last
p-state.
Is the rule that we should not touch the kernel as possible as we can?
Thanks,
-Aubrey
