Li, Aubrey wrote: > Eric Saxe wrote: > > >> I added the basic plumbing to have the the processor group framework >> query the CPU Power manager about power manageable CPU groupings, and >> then instantiate those groupings so that the dispatcher can implement >> scheduling policies against them. >> >> The CPU power manager just has stubbing routines at this point...just >> enough to create some power processor groups. Looking ahead, I believe >> the CPU power manager should query the CPU PM platform driver (which >> will in turn ask ACPI) to enumerate the groupings and power states. >> >> Also, the CPU power manager needs interfaces from the platform >> driver to >> implement the state changes for CPU resources. >> >> That should be enough mechanism for us to sprinkle some policy over to >> get a basic functional prototype, I think. :) >> >> Mark, Anup, do you guys have some code we could populate into >> cpu_pm.c and cpu_pm.h? >> >> > > Didn't get a chance to look at the code. > Will PAD tell the platform CPU PM driver the next idle type the > proccessor > should go into? Or Does the next idle type still need to be obtained > from > the c-state framework itself? >
PAD data will be a huge hint to the idle thread for which c-state it can enter. We have several models to try. :-) Here is what we are planning: CPUs in low power group will always attempts to enter the deepest c-state possible with a latency some multiple less than the time till the next cyclic. Idle threads will keep track of its success rate in entering the deeper c-states. We do not yet know if success-rate data needs to be used in the low-power- processor-group c-state policy. CPUs in the higher power groups have a larger chance a thread will be dispatched on them before the next cyclic expires. We are not sure yet how to model this prediction. Success data will probably be very important here. The success data will come from the c-state framework. Bill > Thanks, > -Aubrey > _______________________________________________ > tesla-dev mailing list > tesla-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/tesla-dev >
