Li, Aubrey wrote:
> Li, Aubrey wrote:
>
>> Juergen Keil wrote:
>>
>>> 3. did confuse me, too. But I think the loop isn't wrong,
>>> it just wastes time. When the walk function is called
>>> for cpu N, the data we read in the loop for cpu
>>> index != N is 0.
>> Right, I realized data->dtada_percpu[i] is ZERO if cpu id != i.
>> But I still suggest we fixed this in the specific cpu way. It seems
>> we still need to figure out why the duration is negative here other
>> than just ignoring the invalid value.
>
> Okay, the problem here is, we snapshot the time to calculate "g_interval"
> is before we snapshot the dtrace aggregation. So sometimes "dtrace_time"
> is larger than "g_interval", especially when we keep pressing "R" key.
>
> The current suggestion should work
>
> +++if (duration < 0)
> +++ duration = 0;
>
> But a better solution is, we move the gethrtime() after the dtrace
> aggregation snapshot.
>
> Does this make sense?
>
> -Aubrey
dtrace_time will be larger than the interval when the system was in a
state for a period longer than the interval, and then transitioned to
another. So I don't think moving the gethrtime() call will solve the
problem. Maybe I'm missing something here..
I was thinking of alternatives to how cpufreq.c works, even though the
current seems optimal in terms of memory usage. It's a little late here,
but I think that if we added a clause like this
profile-$1
{
last[cpu] = timestamp;
}
to the DTrace script, and supplied the interval as an argument, we'd be
able to get the residency values we need without doing all of the
current math. This sets the last firing of cpu-change-speed to the point
in time where we're re-starting the interval (modulo some delta between
dtrace and ptop's interval), effectively limiting the maximum residency
value to the interval. profile probes fire on every CPU, so we'd be
clearing the value for all positions in the last vector.
How does that sound ?
Thanks,
Rafael
