Power management policy has evolved over the years. The earliest policies consisted of little more than some critical temperature sensors and an interrupt routine that attempted (often unsuccessfully) to cleanly shut down the system before something really bad happened. Today’s sophisticated power management policies do such things as progressively shutting down parts of processor circuitry during idle with almost no impact upon performance, rapidly alternating between idle and active states, reducing processor frequencies, exploiting thermal lows to temporarily overclock the processor, and a host of other things.
EXAMPLE POLICY #1: This is one of the simplest policies. It was used in a real-time system I worked on so long ago that its existence has faded from human memory. A few well-placed temperature sensors and some hardware logic were placed on the processor’s boards. When the sensors reached certain thresholds, the hardware logic generated a high priority hardware interrupt. The interrupt routine did its best to save system state and shut down the power before anything really unpleasant occurred. To say it a different way, the policy was to save system state and cleanly shut down the system if the temperature of the hardware exceeded a certain preset threshold. I recall that it was successful only 50% of the time.
EXAMPLE POLICY #2: I wrote briefly about this policy in my previous blog on T-states; see reference [TSTATES] below. This policy uses a technique that is a precursor to P-states to give the processor a chance to cool while not interfering with the execution of most applications. When the temperature of the processor exceeds a certain threshold, the processor’s clock will start and stop with a certain duty cycle. The periods where the clock stops (i.e. is gated) allow the processor to cool. Though this slows down a running application, it ceases running when the clock is stopped, the impact for most applications is minimal outside of taking longer to execute. The exception is when the application depends upon time sensitive external events, such as externally triggered interrupts.
EXAMPLE POLICY #3: P-states. I’ve written about this quite a bit. See Power Management States: P-States, C-States, and Package C-States, reference [CPSTATES] below. Like T-states, it allows the processor to cool by slowing down applications. Unlike T-states, it is far less disruptive as the chip temporarily operates as if it has a slower oscillator, something that the design of most general purpose digital devices can accommodate. Check out the Intel® Xeon Phi™ Coprocessor System Software Developers Guide [SDG], June 2013, Figure 3-2 “Power Reduction Flow”, for an example of P-state power transition logic. As the processor is always running, slowing down the clock doesn’t affect the processing of most external events/interrupts.
EXAMPLE POLICY #4: C-States. I’ve talked about this so much that even I’m a little bored. Saying anything else will serve no purpose except to put the reader to sleep. See reference [CPSTATES] below.
EXAMPLE POLICY #5: Remote power management. In the case of the Intel® Xeon Phi™ coprocessor, part of the power management is remote. See my discussion in Power Management States: P-States, C-States, and Package C-States, reference [REMOTE]. The processor shuts down to such an extent that it is no longer capable of responding to waking events. Shutting down provides you with the ultimate in power savings as your usage is, for all intents and purposes, 0 Watts. Unfortunately, the disadvantage is significant; once you remove all the power, you can no longer respond to waking events, say from the PCIe bus. To say it another way, you cannot leave the “off” state without some external intervention, a.k.a., the host.
You can see the advantage of this in that power usage can theoretically be zero Watts. This is quite a power savings. Unfortunately, it comes at a cost, namely that this deepest power state will last for a very long time, actually forever, unless someone flips the power switch of the processor back on.
What’s up next? We’ll wrap up the general part of this discussion with a summary and a look at future possible policies.
NEXT: SUMMARY AND FUTURE POLICIES
[TSTATES] Kidd, Taylor (2013) “C-States, P-States, where the heck are those T-States?” /content/www/us/en/develop/blogs/c-states-p-states-where-the-heck-are-those-t-states.html. (Downloaded May 14th, 2014)
[CPSTATES] Kidd, Taylor (2014) “Power Management States: P-States, C-States, and Package C-States” /content/www/us/en/develop/articles/power-management-states-p-states-c-states-and-package-c-states.html. (Downloaded May 14th, 2014)
[SDG] “Intel® Xeon Phi™ Coprocessor System Software Developers Guide [SDG], June 2013,” /content/www/us/en/develop/articles/intel-xeon-phi-coprocessor-system-software-developers-guide.html. (Downloaded May 14th, 2014)
[REMOTE] Kidd, Taylor (2014), Power Management States: P-States, C-States, and Package C-States, /content/www/us/en/develop/articles/power-management-states-p-states-c-states-and-package-c-states.html. (Downloaded May 14th, 2014)
Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice.
Notice revision #20110804