LWN: Comments on "Waking systems from suspend"

MythTV

pepsiman — Wed, 30 Mar 2011 12:18:17 +0000

> A few applications out there make use of this interface, such as MythTV
> DVRs, which can trigger alarms so that media computers can be suspended
> until the start of a TV show that needs to be recorded.

MythTV can be configured to suspend, but it normally does a shutdown.

Waking systems from suspend

kevinm — Fri, 18 Mar 2011 03:49:59 +0000

Stopping CLOCK_MONOTONIC during suspend was a mistake - it should always have had the semantics described for CLOCK_BOOTTIME. POSIX is *very* clear on this:

If the Monotonic Clock option is supported, all implementations shall support a clock_id of CLOCK_MONOTONIC defined in <time.h>. This clock represents the monotonic clock for the system. For this clock, the value returned by clock_gettime() represents the amount of time (in seconds and nanoseconds) since an unspecified point in the past (for example, system start-up time, or the Epoch). This point does not change after system start-up time. The value of the CLOCK_MONOTONIC clock cannot be set via clock_settime(). This function shall fail if it is invoked with a clock_id argument of CLOCK_MONOTONIC.

The most common use of CLOCK_MONOTONIC is to determine the time that has elapsed between two events. With the current Linux CLOCK_MONOTONIC, this will give an incorrect result if system suspend happens between the two events.

Waking systems from suspend

jstultz — Mon, 07 Mar 2011 18:16:58 +0000

That might be a good approach. I'll look into it!

Waking systems from suspend

alonz — Mon, 07 Mar 2011 14:39:34 +0000

Wouldn't it be better to just enhance timerfd() so it can take these new types of clock IDs as well as CLOCK_REALTIME / CLOCK_MONOTONIC?

Waking systems from suspend

tpetazzoni — Mon, 07 Mar 2011 07:56:18 +0000

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.

Waking systems from suspend

jstultz — Sat, 05 Mar 2011 23:34:23 +0000

clock_nanosleep() might be one possibility?

Although from my brief discussions with Arve it sounded like the semantics of the android alarm timer interface is a little particular (especially with regards to wakelocks), so I doubt there will be an alternate implementation that will provide an exact 1:1 mapping.

That said, the rework of the RTC layer as well as the implementation of CLOCK_BOOTTIME (tglx just pulled it into -tip) will hopefully greatly simplify the android alarm timer code. So there may be a future for both the posix alarm timers and some form of the /dev/alarm device to co-exist, sharing a good bit of code.

Even so, while I think the posix interface for alarm timers provides a fairly nice and consistent interface that application developers are used to using, I'd greatly appreciate feedback and suggestions for alternative interfaces. Maybe we need something like clock_select()?

Waking systems from suspend

swetland — Sat, 05 Mar 2011 07:48:58 +0000

We (the Android Kernel Team) expect that we will be able to move to the driver level API side of the wakelock/suspendblock work to shift our driver work to be mainline-friendly.

The last proposals I've seen around userspace interface and suspend interface involve polling/spinning and I doubt we'll make use of them. The nice thing is this is pretty localized so it'll be easy enough to maintain patches for a reasonable userland interface on our side and not have to worry about any special changes for drivers. A nice step forward.

Regarding timer interfaces, are there non-signals-based ways of interacting with posix timers? Being able to select() on an fd for an alarm event works very well for us now and we're not terribly keen on moving to a signals-based universe.

Waking systems from suspend

ofeeley — Fri, 04 Mar 2011 18:41:00 +0000

Nice to see some useful contributions from the android cousins!

Waking systems from suspend

jstultz — Thu, 03 Mar 2011 18:54:30 +0000

So, I think for future debugging, the question of "why a system woke up" is quite useful. Its possible something similar to the /proc/timers_list would be wanted so analisys applications similar to power-top can monitor why we are waking up.

But I think "why a system woke up" question is probably less important then the decision of "when should it go back to sleep?".

Currently suspend is initiated by userland. So its outside of the kernel's scope for the moment.

But I can see one potential issue where maybe there's a system that will suspend after 15 minutes of X-idle. A alarm timer fires, and then wakes the system to do some work, but that work takes longer then 15 minutes, so the work gets cut off when the system suspends again.

You could have the application contact the power-management daemon and inhibit suspend while the critical work was being done (much like how slideshow or movie applications do this). This would probably work for the most part, but there are still some races between the wakeup and the userland inhibit message being sent.

And indeed, as Paul mentioned there are a number of different approaches being worked with here, with wakelocks being the most contentious, but also most complete.

Waking systems from suspend

PaulMcKenney — Thu, 03 Mar 2011 17:52:20 +0000

The trick used is a handoff of responsibility from the kernel to userspace. Userspace knows what device woke up the system because it just interacted with the corresponding device driver, and can then decide whether or not to continue holding off suspend. The kernel therefore only needs to hold off suspend until userspace has started the interaction, where this interaction might be a read() system call. So userspace would hold off suspend just before doing the read(). The kernel would stop holding off suspend as part of the read(). After the read() returned, userspace would use the data read to determine whether it should keep holding off suspend, and, if not, stop holding off suspend.

According to the Android developers, wakelocks handle this handoff in a natural way. Others argue that all of the suspend-blocking work should happen in user space, so that the kernel does not need to worry about it. And there are probably a large number of other opinions out there about how all of this should work, both informed and otherwise. ;-)

Waking systems from suspend

johill — Thu, 03 Mar 2011 17:11:36 +0000

:-) I'm genuinely interested since we'll eventually run into more of this on more platforms, say a tablet.

The APIs you mention, do they actually allow you to know what device woke up the system? I thought they were mostly for not going to suspend.

Waking systems from suspend

PaulMcKenney — Thu, 03 Mar 2011 16:49:00 +0000

Are there any good interfaces? Well, yes there are, but unfortunately, different groups have wildly conflicting definitions of what constitutes “good”. The Android developers swear by wakelocks, but wakelocks have not been warmly received by many in the Linux kernel community (see here, here, here, here, here, here, here, and here). Many in the Linux kernel community swear by extensions to PM QOS, but the Android developers do not believe that these extensions are capable of replacing wakelocks — though these extensions might allow Android device drivers to be accepted into mainline, which would be very worthwhile in and of itself.

Hey, you asked!!! ;–)

Waking systems from suspend

johill — Thu, 03 Mar 2011 09:39:26 +0000

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

tpetazzoni — Thu, 03 Mar 2011 09:20:22 +0000

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

johill — Thu, 03 Mar 2011 09:08:05 +0000

What I'm wondering about -- are there good interfaces to know why the system woke up? If there aren't, then the cron thing might not work all that well on a standard desktop since you wouldn't want it to go to sleep again when you woke it up by pressing the button, rather than by a timed trigger.

It seems to me that there will need to be some good management around these "why did we wake up" and "should we go to sleep again" stories.

Waking systems from suspend

josh — Thu, 03 Mar 2011 08:46:44 +0000

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

jstultz — Thu, 03 Mar 2011 07:11:21 +0000

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

josh — Thu, 03 Mar 2011 05:37:34 +0000

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.