User: Password:
|
|
Subscribe / Log in / New account

Waking systems from suspend

Waking systems from suspend

Posted Mar 3, 2011 5:37 UTC (Thu) by josh (subscriber, #17465)
Parent article: Waking systems from suspend

Eventually, if we can ever get systems to suspend and resume in tens of milliseconds, and have some additional control over what devices remain powered (such as not turning off the screen), we can finally start suspending systems between interrupts when no processes need to run, rather than just putting the CPU to sleep.


(Log in to post comments)

Waking systems from suspend

Posted Mar 3, 2011 7:11 UTC (Thu) by jstultz (subscriber, #212) [Link]

Yes, the OLPC folks actually use a very similar strategy: http://wiki.laptop.org/go/Suspend_and_resume

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.

Waking systems from suspend

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".

Waking systems from suspend

Posted Mar 3, 2011 9:20 UTC (Thu) by tpetazzoni (subscriber, #53127) [Link]

This is something I implemented on a Blackfin system (Blackfin is a DSP architecture that runs the Linux kernel), which can enter suspend and get out of suspend in about 3-4 milliseconds.

So I modified the idle loop of the kernel so that if the next timer expiration event is enough far away in the future (say, 20 or 30ms), then I program the RTC to wake-up a few milliseconds before the scheduled expiration and then enter suspend. When I come back from suspend, I tweak the clocksource to make the system think that the time has continued to pass while the system was suspended, which has the effect of rescheduling the timer events so that the interrupt fires at the correct expected date, as if the system didn't enter suspend. It has been checked with an external scope that looks at GPIO toggling triggered by userspace Linux timers *and* the CPU voltage, and the frequency of the GPIO toggling was correct, and the CPU was completely off during the waiting periods.

I feel that suspend and idle are considered as two very separate things by many kernel developers, because on x86, suspend is such a slow operation that it can only be started explicitly by the user. But on many embedded architectures, suspend can just be a specific type of idle state.

Waking systems from suspend

Posted Mar 3, 2011 9:39 UTC (Thu) by johill (subscriber, #25196) [Link]

So, now we're curious: How much power did that save over just being idle? I think Blackfin is pretty low-power already?

Waking systems from suspend

Posted Mar 7, 2011 7:56 UTC (Mon) by tpetazzoni (subscriber, #53127) [Link]

I don't have the numbers anymore, but yes the difference was quite huge between idle and off. At least sufficient for motivating a fairly huge amount of work to get off-while-idle working on this platform.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds