Bill.Holler wrote:
> Very cool!
>
> Can this heuristic be applied to C-State power domains as well?
>
I doubt it. We don't need polling mechanism for c-state. c-state transition
has a different event driving.
With the new change of p-state, is the transtion already removed from
the polling scanning of the current pm framework?
Thanks,
-Aubrey
>
>
> On 10/07/08 16:55, Eric Saxe wrote:
>> I've just been testing some changes I made to improve the PAD
>> P-state transition policy.
>>
>> Before, PAD would ramp up the max speed as soon as the P-state domain
>> went non-idle, and then ramp it back down the instant it goes idle
>> again.
>>
>> Running this script on that kernel, focusing on an idle CPU:
>>
>> #!/usr/sbin/dtrace -s
>>
>> #pragma D option quiet
>>
>>>> ess_transition
>> /curcpu->cpu_id == $1/
>> {
>> x++;
>> }
>>
>> profile-1s
>> /x > 0/
>> {
>> printf("%d\n", x);
>> x = 0;
>> }
>>
>> I would get ~140 transitions per second. With the new changes, we
>> don't transition an idle P-state domain up to full speed until the
>> first thread that begins running there either makes it through one
>> time quantum, or transitions to another non-idle thread. This gets
>> rid of the transitions we were doing simply as a result of transient
>> background kernel activity, reducing the rate down to 2-4
>> transitions per second...and 0 per second once the domains are
>> busy....
>>
>> -Eric
>> _______________________________________________
>> tesla-dev mailing list
>> tesla-dev at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/tesla-dev
>>
>
> _______________________________________________
> tesla-dev mailing list
> tesla-dev at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/tesla-dev
