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 > >> >> 2009/4/16 Rafael Vanoni <Rafael.Vanoni at sun.com>: >>> Li, Aubrey wrote: >>> I agree with these first two, I need a little more time to properly >>> check 3 and 4. I'll get back to you as soon as possible. >>> >>> Thanks, >>> Rafael >>> >>>> 3) I failed to understand why the current walk function need to go >>>> through all CPU to get the dtrace time everytime to fill a per-cpu >>>> array(g_cpu_power_states). That might be the reason why duration < >>>> 0. So change to count the specific cpu only. >>>> >>>> 4) if we have the condition check (dt_state_time > >>>> cpu_pow->time_accounted), we also >>>> need to check the opposite case. time_accounted should be reset if >>>> it's not used by this time. >>>> >>>> If the following patch makes sense, we'll have to fix the similar >>>> cstate issue. > > _______________________________________________ > tesla-dev mailing list > tesla-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/tesla-dev
