Power7 as a study in power-management strategy
The IBM Power7 architecture unveiled at Hot Chips this week provides an interesting case study in energy management. In a time when chip architects are emptying their toolboxes to find ways to tease out every last milliWatt from their designs, the Power7 designers took a surprisingly conservative approach.
It’s tempting to explain this seeming anomaly by pointing out that the Power7 chip is for really big computers, not battery-powered handsets. But in fact energy is just as critical for big iron as it is for pocket rockets, due to energy-density and cooling issues in large systems and the intractable power profiles of DRAMs, which put all the responsibility for energy efficiency on the logic. So the IBM team’s strategy in Power7 represents intent, not lack of emphasis.
Power7 chief engineer Ron Kalla explained the power-management plan for the chip with a simple graph of power reduction vs. latency. As you would expect, there is a direct but not linear relationship between how much power a mode saves and how much time it takes to get out of it. If for instance you just turn down the clock frequency, you don’t save much power, but you can turn the frequency up again quickly. If you gate-off the power to a block you save all the power, but it may take ten thousand cycles to get the power up and stable, restore the state, and open the isolation gates around the block.
According to Kalla, the Power7 designers chose to implement just two points on this curve, which he referred to as Nap and Sleep. Nap mode gates most of the clocks in the CPU core, but maintains the core operating voltage. Sleep mode gates all the clocks, and reduces the supply voltage from operating level to the minimum necessary for data retention. In addition, during full operation of the chip IBM does dynamic voltage-frequency scaling over a range from barely operating to a turbo mode where power gets diverted to the critical paths in the design from less critical areas. But the chip apparently does not use power gating at all.
Given the lengths designers in the media and handset SoC worlds go to in order to implement power gating, that must seem strange. But the explanation is the apparent difference in operating environment between a heterogeneous cluster of embedded processors with static task mapping and a computing cloud with hardware memory coherency.
In for example a smart phone, SoC designers can plausibly expect enough advanced warning to be able to use long-latency power-down modes effectively. If the user turns off the radio, or turns on the video player, you have thousands of cycles before the delay becomes perceptible. Even in the baseband chip, air interface protocols have been designed so that you can monitor the link at quite low power and wake up the rest of the processing only when it’s necessary.
But a symmetric multiprocessing supercomputer, exactly because it is user-programmed, symmetric, and dynamic, does not offer that luxury. Even when you know the application in detail it is not necessarily possible to predict when a particular thread will become active on a particular CPU. The more the hypervisor moves tasks around, the less start-up latency the system can absorb. And with the hardware coherency network continually hitting various levels in the memory hierarchy, you have to be very careful what you turn off even when there are no active threads.
The Power7 does a nice job of illustrating the different responses architects have taken to the two problems. But it may also be a model of what power-saving modes we can actually expect to use in embedded computing, given our incomplete understanding of the modes of operation of the system and given the relative lack of information coming from the software. It may be that in the real world a lot of the effort that has gone into power gating will turn out to be wasted, and the Power7 architects’ choices will look pretty correct for the SoC problem as well.
