Aubrey Li wrote:
> On Wed, May 21, 2008 at 9:44 PM, Rafael Vanoni <Rafael.Vanoni at sun.com>
> wrote:
>> Li, Aubrey wrote:
>>> Rafael Vanoni wrote:
>>>
>>>> Here's a patch for this one, basically raising the event report
>>>> according to the number of P/C states.
>>>>
>>>> Let me know what you think.
>>>>
>>> moving subwindows is not a good idea, it caused segment fault sometimes
>>> on my side. "man mvwin" told me moving subwindows is allowed, but should
>>> be avoided.
>>>
>>> we may setup window after we get ncstates and npstates, so that we can
>>> dynamically position the event report window based on the numbers.
>>>
>>> Does it make sense?
>>>
>>> Thanks,
>>> -Aubrey
>> The only safe way I see of doing this is to set a define for the number
>> of C state transitions we currently support. Which is hacky :|
>>
>> I think the problem here is that we're allocating blank lines according
>> to the number of known states, regardless of how many the system/OS
>> actually supports. Without the kstat c-state info, I don't see a good
>> way of fixing this bug besides hand coding.
>>
> after pt_cpuidle_stat_collect(), we actually know the number of
> c-state supported.
> We may just need to take the following piece of code from show_cstate() to
> pt_cpuidle_stat_collect()
> ----snip----
> for (i = 0; i < NSTATES; i++) {
> if (cstate_info[i].total_time > 0) {
> total_time += cstate_info[i].total_time;
> if (i > max_cstate)
> max_cstate = i;
> }
> }
> ----snip----
Hmm.. ok, I overlook pt_cpuidle_dtrace_walk as an argument to
dtrace_aggregate_walk_keyvarsorted(). Sorry, bad coffee ;)
But we're still only reporting C-states that the processor transitions
to. If the system supports Cn, we only report it's existence after the
first transition to it. If this is the desired behavior, we gotta update
the manual.
thanks
Rafael
