That said, the suggestion isn't that far away from some of the run-time power-management approaches being worked on, where unused hardware is shutdown, and scheduling policies regulate what can execute while the system is "running". This would ideally, given proper hardware support, allow the same power-efficiencies as suspend when the system is idle.
I think both approaches are important. Runtime power-management makes the most of hardware features to save power while minimally impacting system latencies. While suspend power-management further restricts what the system will respond to, but possibly greatly increasing latencies.
If suspend/resume gets fast enough, and run-time power-management features in hardware get good enough, the two approaches might converge. And choosing which to use at that point might be a wash. But for now, I think its important that we chip away at the power-saving problem from both sides.
Posted Mar 3, 2011 8:46 UTC (Thu) by josh (subscriber, #17465)
[Link]
I agree with you that we would ideally like every individual component to support low-power or no-power states equivalent to those used by suspend. If all devices supported that, I don't think we'd need suspend at all. You'd just have a set of independent policy decisions like "do we want to keep the network card alive to maintain a link and provide interrupts when we get packets".