Blocking suspend blockers

By Jonathan Corbet
May 18, 2010

When LWN last looked at suspend blockers in April, it appeared that this functionality was on a path to be merged into the mainline sometime soon. It may still be on that path, but an extended discussion has muddied the picture somewhat. It is a relatively small and obscure bit of code, but the fate of suspend blockers may have significant implications on how the kernel community deals with external projects in the future.

Suspend blockers, remember, are tied to the "opportunistic suspend" mode used by the Android system. In this mode, the kernel is placed into a sort of controlled narcolepsy; it will fall asleep (suspend the system) just about anytime that somebody is not actively prodding it. A suspend blocker is a form of prod which can be used to keep the system awake while some sort of important processing is going on. As long as there are suspend blockers outstanding, the system will not suspend.

There are two aspects to this approach which sit well with the Android developers. One is that they are able to get better power performance (longer battery life) by suspending the entire system whenever nothing is going on. Using normal runtime power management does not give them the same results. The other key point is that opportunistic suspend can happen even when processes are running in user space. In the absence of a suspend blocker, any computation underway is not considered to be important enough to keep the system awake. This behavior is a form of defense against poorly-written applications which might, otherwise, drain a system's battery in a short period of time.

Suspend blockers have few enthusiastic supporters. Opportunistic suspend seems like a bit of a hack, and the need to put suspend blocker calls into drivers looks invasive. Even if this feature is configured out of most kernels, it looks like it could be a maintenance burden going forward. Even so, most of the developers involved - including almost everybody involved with Linux power management - have concluded that nobody has any better ideas. So, as Matthew Garrett put it:

Look, I don't want to sound like I have a one-track mind or anything, but all of these arguments would be significantly more compelling if someone would actually provide a concrete implementation proposal that deals with the set of use-cases that Google's implementation does and which doesn't make anyone cry. Otherwise the immeasurably most likely outcome is that this code gets merged and we get to live with it.

Requests for alternatives have been posted a number of times in this discussion, but actual proposals have been rather rare. A number of the suspend blocker opponents seem more interested in changing the use case - mandating that all Android applications be well written, for example. The problem is that users will blame the device (rather than that new dog whistle application) if its battery fails to last long enough. So the Android developers must choose between somehow forcing good behavior on all application developers (perhaps losing the "open to all" feature that is at the core of the Android way of doing things) or creating a system robust enough to function with non-ideal applications installed.

The Android developers have taken the latter approach. In the process, they have made suspend blockers a key part of their platform. Many of the drivers which have been developed for Android have suspend blocker support built into them; they cannot be merged in their current form if the suspend blocker API is not available for them. So the current alternatives are to keep those drivers out, or to hack out the suspend blocker usage before merging them. In the former case, we have more out-of-tree code; in the latter case, we have in-tree drivers which are not actually used, tested, or maintained by anybody. Neither alternative looks good.

Merging suspend blockers would make it easier to get much of the rest of this code in; as Android developer Brian Swetland said:

With wakelock support in the kernel, I'm able to maintain drivers that (provided they meet the normal style, correctness, etc requirements) that both can be submitted to mainline (yay!) and can ship on production hardware as-is (yay!). Porting other linux based environments to hardware like G1, N1, etc becomes that much easier too, which hopefully makes various folks happy.

This helps get us ever closer to being able to build a production-ready kernel for various android devices "out of the box" from the mainline tree and gets me ever closer to not being in the business of maintaining a bunch of SoC-specific android-something-2.6.# trees, which seriously is not a business I particularly want to be in.

("Wakelocks" are the old name for suspend blockers).

Google and Android have taken a lot of grief for their failure to work with upstream and get their code into the mainline kernel. There can be no doubt that their code could have been handled better; had the Android developers worked with the kernel community before shipping this functionality in millions of handsets, perhaps much of this trouble could have been avoided. But that history cannot be rewritten now; not even the secret git "plumbing" commands can make that happen. But we can try to improve the situation going forward.

The suspend blocker effort looks like a real attempt to do better. The code has not just been posted; it has been through rather more than the usual number of revisions as its developers have put considerable time into trying to address comments which have been made. A failure to merge it would be demoralizing at best. If the development community refuses this attempt to bring Android and the mainline closer, it risks creating an impression of bad faith at best. If we do not accept their code, we really should not complain about them maintaining it outside of the mainline.

As of this writing, the 2.6.35 merge window is open. What will happen with suspend blockers is anybody's guess. The power management developers are in favor of merging it, but some others have made a fair amount of noise and Linus has not made his feelings known. So it is hard to say whether this long story is about to come to a close or not.

Index entries for this article
Kernel	Android
Kernel	Power management/Opportunistic suspend

to post comments

Blocking suspend blockers

Posted May 20, 2010 4:22 UTC (Thu) by brendan_wright (guest, #7376) [Link] (37 responses)

The argument that suspend blockers aren't needed because "applications shouldn't waste power" is like saying that the kernel doesn't need to enforce security policies because "applications shouldn't modify system files".

Landing at an airport in a foreign country and finding you can't access your emails/maps/whatever because the last app you installed on your Android device had a bug in it causing it to flatten your battery would be a Big Problem for many people. It seems that suspend blockers are the only reasonable solution proposed so far. Merging some form of them would make Linux a much more reliable solution for "open" portable devices.

Blocking suspend blockers

Posted May 20, 2010 4:36 UTC (Thu) by dlang (guest, #313) [Link] (36 responses)

umm, I think you may be misunderstanding this.

suspend blockers will let an application tell the system that it is not allowed to suspend. This makes it far _more_ likely that you will have a buggy (or just plain poorly written) app that causes your device to run out of battery.

Blocking suspend blockers

Posted May 20, 2010 4:44 UTC (Thu) by wblew (subscriber, #39088) [Link] (13 responses)

The point is this: without suspend blockers, the portable device's userland cannot aggressively suspend itself. After all, how is it to know that device driver X is preventing suspension?

Hence suspend blocker leads to aggressive userland initiated suspend, right?

Or, maybe _I_ am missing something... which is certainly possible.

Blocking suspend blockers

Posted May 20, 2010 5:18 UTC (Thu) by dlang (guest, #313) [Link] (12 responses)

no, all that suspend blockers do is to tell the system that while suspend is blocked, don't run your normal heuristics.

When suspend is not blocked, the system can run the heuristics to decide if it should suspend or not.

suspend blockers may allow yo to set the system heuristics to be more aggressive, but if you have any apps on the system that do not invoke suspend blockers, you run the risk of suspending too aggressively when those apps are running.

And if an app claims that you should not suspend (by setting a suspend block), then the system will never go to sleep.

this is very similar to cooperative multitasking, when all apps are well written it can work _very_ well (and can be far more efficient than premptive multitasking), but it only takes one badly written app to cripple the system.

There's a reason that there are basically no commonly used cooperative multitasking systems, in the real world they just aren't reliable enough. The only place you can really use them is in embedded situations where you control everything that's running on the system. That no longer includes phones as people can download apps to run on them.

Blocking suspend blockers

Posted May 20, 2010 7:02 UTC (Thu) by neilbrown (subscriber, #359) [Link] (11 responses)

If what you say is true (and I'm afraid I haven't been able to follow the discussion at all closely) then it would seem to make sense to only allow selected applications to block suspend, with only the device distributer and the device owner allowed to make that selection.

What I don't quite see is why device drivers want to impose suspend blocks. Does anyone know an example of a device driver that needs to do this? I would have thought that the decision of whether to suspend would be entirely up to user-space. Obviously a device can say "just a moment, I need to tidy up a bit first", but otherwise it should just do what it is told.

Blocking suspend blockers

Posted May 20, 2010 7:15 UTC (Thu) by dlang (guest, #313) [Link] (3 responses)

I may be misreading things as well, so it will be interesting to see others comments on this.

As for why drivers need to block suspend, if you set the system to be hyper eager to suspend, then you can't count on getting anything finished unless you block suspend.

if for example, your driver needs to send a string of bytes to your GPS chip to initialize it, having the system sleep in the middle can leave you with a uninitialized device that won't work when you wake up and pick up where you left off, so you need to block suspend while you do this 'critical, uninterruptible' work

the problem that I see is that I haven't seen anything that would prevent an application from claiming that everything that it's doing is critical. It's definitely easier for joe random game developer to just tell the system to not suspend while the game is running than it is to properly handle being suspended.

sometimes an app blocking suspend is the right thing to do (think a 'flashlight' app that just displays an all-white screen and prevents the system from sleeping until you do something to turn it off), but without any way for the system to prevent abuse, it's only going to be a short time before apps start abusing it.

Blocking suspend blockers

Posted May 20, 2010 9:39 UTC (Thu) by farnz (subscriber, #17727) [Link] (2 responses)

The trick, in Android world, is that only a limited set of known processes can actually set suspend blockers (just as in POSIXy Linux world, only a limited set of processes can write to /dev/sd*). Everyone else who wants to block suspend has to ask one of the privileged processes to set a block for them, using Android's RPC mechanism. An Android app comes with a manifest file, and in that manifest file, you must declare if you wish to take out a suspend blocker. This translates in UI terms to a warning when the application is installed, telling you that the application can "prevent phone from sleeping", and to Android's "where's my battery gone" UI and APIs blaming applications that hold a suspend blocker for the resulting power consumption.

Thus, on a phone, if you take out a suspend blocker via the RPC mechanism, you get blamed whenever the user asks the phone "why's my battery life poor?", even if it's another app hammering the CPU and keeping you out of idle. The hope is that this will be enough to stop application writers from using suspend blockers when they're not needed.

Blocking suspend blockers

Posted May 20, 2010 18:33 UTC (Thu) by felipebalbi (subscriber, #56613) [Link] (1 responses)

That's not what some android developers said on the discussion, they said anyone can take a suspend blocker and like I replied to them, if you only want suspend blockers to pretty print on UI, there are other less invasive and transparent to apps mechanisms to do so. You don't need opportunistic suspend and suspend blockers.

Blocking suspend blockers

Posted May 20, 2010 20:12 UTC (Thu) by broonie (subscriber, #7078) [Link]

For all practical purposes any app can take a suspend blocker - there's no opportunity for users to tweak the set of permissions an application has, it's fixed by the app developer. However, the UI does warn the user during installation that the app might do this and does provide the accounting that's been discussed.

Blocking suspend blockers

Posted May 20, 2010 18:30 UTC (Thu) by felipebalbi (subscriber, #56613) [Link] (6 responses)

Imagine what would happen if you suspend while usb cable is attached. You don't really know whether pc has mounted the file system (considering you're using mass storage) and if the pc is transferring files to device, since with mass storage we need a 2 second poll for media change and there's no way to differentiate those IRQs from actual _data_ coming to device. They're all endpoint IRQs.

If you forcefully suspend at that point, you're risking corrupting user's Data.

Also, we can get pretty much the same power consumption with cpufreq + cpuidle + runtime pm since idle consumption is HW characteristic, not SW. If we don't reach that level, it only mean device isn't idle enough and there's some cripple app waking up the processor.

Blocking suspend blockers

Posted May 20, 2010 19:40 UTC (Thu) by sfeam (subscriber, #2841) [Link] (5 responses)

That seems to be an argument in favor of suspend blockers, rather than against them. That "actual _data_" operation can be protected by a suspend block, while the period poll for media change is not. What level the suspend blocker is invoked from to bracket a data transfer is a separate question.

I may be missing your point about suspending while a usb file system is mounted. If you can suspend your laptop while the hard drive is mounted, isn't it equally desirable to be able to suspend it while a memory stick is mounted? I imagine that a forceful suspend would necessarily trigger a sync operation, but isn't that true anyhow?

Blocking suspend blockers

Posted May 21, 2010 1:30 UTC (Fri) by dlang (guest, #313) [Link] (4 responses)

a problem with suspending while a USB device is connected is that it's highly likely that the USB device will no longer be connected when the system tries to come back up from being suspended.

Blocking suspend blockers

Posted May 22, 2010 8:19 UTC (Sat) by quintesse (guest, #14569) [Link] (3 responses)

But that's a problem the system has to deal with anyway, the user can yank out the cable at any time.

Blocking suspend blockers

Posted May 22, 2010 18:48 UTC (Sat) by giraffedata (guest, #1954) [Link] (2 responses)

But that's a problem the system has to deal with anyway, the user can yank out the cable at any time.

The system more options to deal with the user yanking out the cable, because the user expects yanking the cable to interrupt use of the device, and the user can arrange not to yank the cable if it is a problem. In contrast, suspend happens all by itself at largely arbitrary times, so the user won't expect interruption and can't practically avoid it.

Blocking suspend blockers

Posted May 22, 2010 22:00 UTC (Sat) by sfeam (subscriber, #2841) [Link] (1 responses)

The system has more options to deal with the user yanking out the cable, because the user expects yanking the cable to interrupt use of the device, and the user can arrange not to yank the cable if it is a problem. In contrast, suspend happens all by itself at largely arbitrary times, so the user won't expect interruption and can't practically avoid it.

Huh? The point is that suspend/resume should be harmless with respect to a device that is still plugged in.

If the device is still plugged in when the system resumes, open files should still be open, etc. This already works with the hard drive; is it really so hard to re-establish communication with a usb device?
If the device is gone when the system resumes, that's a problem, yes. But it's the same problem as just yanking the cable while the system is active. Or hold on, it's actually a less serious problem, because we should have been smart enough to sync during the suspend process, whereas there was no opportunity to do so during the cable yanking.

Blocking suspend blockers

Posted May 22, 2010 22:32 UTC (Sat) by giraffedata (guest, #1954) [Link]

Oh, I misunderstood "connected" as in the device may not be connected when the system wakes up. "Connected" is a logical state to me, but I can see it was supposed to mean plugged in.

I agree. There's no issue with a cable being yanked while the system is asleep that doesn't also exist for the cable being yanked while it's awake.

Well, except that since going to sleep correlates with a lull in user activity, there's a higher chance of that yank happening while the system is asleep. But since preventing the sleep won't prevent the lull in user activity, I don't suppose that's relevant to the question of whether suspension should be blocked.

Blocking suspend blockers

Posted May 20, 2010 7:49 UTC (Thu) by MisterIO (guest, #36192) [Link] (3 responses)

No, you missed a part of it. The article explained that the Android system aggressively suspends whenever it can(for example it could suspend even when a userspace app is doing some work) and thus it needs suspend blockers to force the system to not suspend. Thus suspend blockers are what makes possible the aggressive suspend capability of the Android system. Even a buggy app won't stop the system from suspending if, at the time, the suspend blocker won't block the suspend.

Blocking suspend blockers

Posted May 20, 2010 7:52 UTC (Thu) by MisterIO (guest, #36192) [Link] (1 responses)

Clear example of a comment I'd like to cancel.

Blocking suspend blockers

Posted May 20, 2010 17:56 UTC (Thu) by dlang (guest, #313) [Link]

which part of the post did you wish to cancel?

Blocking suspend blockers

Posted May 20, 2010 18:34 UTC (Thu) by felipebalbi (subscriber, #56613) [Link]

If you have an application that holds a suspend blocker forever, device will never "aggressively suspend" whatever that means.

Blocking suspend blockers

Posted May 20, 2010 10:41 UTC (Thu) by brendan_wright (guest, #7376) [Link] (17 responses)

Android's implementation of suspend blockers allows it to suspend the system aggressively without worrying about interrupting anything important (such as a download). And for many apps it achieves this without any risk that the app will block suspend no matter how buggy it is, because only some apps have access to the suspend blocker API.

Before an app is installed the user is shown a list of access rights the app is requesting. One access right an app can require is to "prevent the phone from sleeping". As many apps don't need this functionality they don't ask for access to the suspend blocker API, and so can't flatten your battery no matter how buggy they are.

Apps that do require access to the suspend blocker API would need to to exhibit buggy behavior *while holding a lock* in order to drain your battery. Android can also show you which apps are using the most power if you are concerned about your battery life.

Desktop distros could presumably not compile the functionality in, or restrict userspace access to the API, if they were concerned about buggy userspace code blocking suspend?

Blocking suspend blockers

Posted May 20, 2010 15:57 UTC (Thu) by intgr (subscriber, #39733) [Link] (5 responses)

> Desktop distros could [...] restrict userspace access to the API, if they
> were concerned about buggy userspace code blocking suspend?

No, desktop distros only support user-initiated suspend, which should never be blocked by user space applications anyway. A desktop computer cannot use opportunistic suspend as it stands, because:
* The hardware is not designed that way; suspending (spinning down) your hard drive every few seconds is a great way to kill it
* Current software does not acquire suspend blockers where they would be expected by the user
* Current drivers do not use suspend blockers, so the system as a whole doesn't know when it *can* suspend. If it tries, chances are that the suspend will be blocked half-way until the driver can finish its work -- time during which the system is still running, but the user cannot do anything meaningful.

This is an Android-specific feature that cannot be reliabily used in other configurations, possibly even other handsets.

Blocking suspend blockers

Posted May 20, 2010 17:59 UTC (Thu) by dlang (guest, #313) [Link] (1 responses)

I don't know what desktop distros you have been using, but every one that I have seen that does suspend does not require the user to explicitly take action to initiate the suspend, they all are setup to suspend after some defined period of 'inactivity'

Blocking suspend blockers

Posted May 22, 2010 20:24 UTC (Sat) by rvfh (guest, #31018) [Link]

But you do expect your movie player to block the screen saver and DPMS off, don't you? Isn't this some kind of user-space suspend blocker?

Blocking suspend blockers

Posted May 20, 2010 23:44 UTC (Thu) by brendan_wright (guest, #7376) [Link] (2 responses)

> No, desktop distros only support user-initiated suspend, which should never be blocked by user space applications anyway.

By desktop distros I mean Ubuntu, Fedora etc that are used on both desktops and laptops. As dlang has pointed out, laptops are often set to suspend after a certain period of inactivity by the user. This non-user-initiated-suspend can and does sometimes interrupt important activities (such as watching a movie, downloading a file etc).

> A desktop computer cannot use opportunistic suspend as it stands, because:
> * The hardware is not designed that way; suspending (spinning down) your hard drive every few seconds is a great way to kill it

Desktops/laptops are certainly different beasts in terms of hardware than mobile devices. A laptop with a solid-state drive (that isn't damaged by a suspend/resume "every few seconds") could potentially handle frequent suspend/resumes whereas a machine with a hard drive couldn't.

Currently we rely on the user or the disto to set reasonable policies in terms of how soon to suspend when running on battery power, but ideally the driver itself would inform the system of it's limitations. A correctly implemented suspend blocker API might be a way to achieve this.

Also Android's userspace API for suspend blockers (which they call wakelocks) supports multiple suspend states:
http://developer.android.com/reference/android/os/PowerMa...

Possibly a suspend blocker implementation would allow devices that are happy to suspend frequently to do so while others are kept active. A user may wish for their dual 24" monitors and 12-core CPU to suspend after 3 minutes of inactivity but not their hard drive (which would suffer too much wear). A well implemented suspend blocker API could allow the drivers to indicate when they are willing to suspend.

> * Current software does not acquire suspend blockers where they would be expected by the user

Of course nobody is using an API that doesn't exist yet. But I think you're assuming that by implementing suspend blockers distros would be forced to suspend very frequently like Android devices do, thereby causing problems for software. There's no reason why they would need to be configured this way.

But by providing the API a browser that's downloading a 600MB ISO from a server that doesn't support resuming could indicate it doesn't want the network & storage systems to be suspended till it's finished. Perhaps this might be sufficient to block a timeout-triggered suspend but a user might still be allowed to force a suspend if required?

> * Current drivers do not use suspend blockers, so the system as a whole doesn't know when it *can* suspend. If it tries, chances are that the suspend will be blocked half-way until the driver can finish its work -- time during which the system is still running, but the user cannot do anything meaningful.

Most laptops running desktop distros are suspended after a period of inactivity when running on the battery. As you point out, they do so without the system really knowing that it can. The system is forced to *assume* that it can because drivers can't tell it otherwise because they have no API with which to do so. Providing this API rectifies this problem.

> This is an Android-specific feature that cannot be reliabily used in other configurations, possibly even other handsets.

I think it's a potentially useful feature for any Linux system that runs off a battery or uses a lot of power.

Blocking suspend blockers

Posted May 21, 2010 9:41 UTC (Fri) by intgr (subscriber, #39733) [Link]

Thanks for this post! You have convinced me.

> A user may wish for their dual 24" monitors and 12-core CPU to suspend
> after 3 minutes of inactivity but not their hard drive (which would suffer
> too much wear).

Is that possible with current PC hardware? To suspend the rest of the system except hard drives?

I always thought that when you suspend the CPU, the rest of the system has to come down too. (Except on Android where hardware was specifically designed to allow this)

Blocking suspend blockers

Posted May 22, 2010 20:29 UTC (Sat) by rvfh (guest, #31018) [Link]

> But by providing the API a browser that's downloading a 600MB ISO from a server that doesn't support resuming could indicate it doesn't want the network & storage systems to be suspended till it's finished. Perhaps this might be sufficient to block a timeout-triggered suspend but a user might still be allowed to force a suspend if required?

This reminds of the way KDE (and I suppose the others too) will stop you from logging off when you have unsaved changes. Indeed, you'd like to have a way to back off when the app tells you 'ongoing download: do you really want to stand-by?'

Blocking suspend blockers

Posted May 20, 2010 18:01 UTC (Thu) by dlang (guest, #313) [Link] (5 responses)

the buggy behavior I expect is to raise the blocker for excessive periods of time (there has to be a way for multiple apps to raise the blocker at the same time, or the concept will fall apart in a multiprocess envrionment)

Blocking suspend blockers

Posted May 20, 2010 23:54 UTC (Thu) by brendan_wright (guest, #7376) [Link] (4 responses)

> the buggy behavior I expect is to raise the blocker for excessive periods of time (there has to be a way for multiple apps to raise the blocker at the same time, or the concept will fall apart in a multiprocess environment)

This is a potential problem. One advantage Android has is that most apps are installed through a market where user comments can indicate to others that software has these kinds of bugs (which should be pretty rare as most code shouldn't need to operate with a suspend block taken).

A user who notices that the problem is occurring could manually kill the app. However they won't always be paying attention to the device.

A battery operated device will eventually die through lack of power anyway, so perhaps devices should choose to ignore an apps suspend-blocking request after a certain amount of battery is consumed. This sort of functionality might seem unnecessarily complex in the desktop world but could be a life-saver in the world of battery operated devices.

Blocking suspend blockers

Posted May 21, 2010 11:03 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (3 responses)

My understanding is that in the Android phone world what happens is this:

User A downloads "cow bouncer" and is impressed that now their phone constantly has bouncing cows. However an hour later their phone bleeps to warn the battery is low. The "low battery" screen shows a "Why so soon?" button or link, which implicates "cow bouncer" as the reason. User A chooses to uninstall the "cow bouncer" app because it's a waste of battery life.

User B downloads "John the ripper Android edition" and sets it to work cracking password hashes. An hour later the phone bleeps due to exhausted battery. User B plugs it into the wall, he doesn't ask why because hey, he was running a password cracker on his phone, stands to reason it will exhaust the battery.

By obligating ordinary developers to ask for this functionality if they need it and then auditing how it is used, Android make them responsible to their users - if you need to block suspend for long periods, you will need to educate your users about why that is, and persuade them that the app functionality is worth the reduced battery life, otherwise they're going to throw your app away and probably warn off other potential customers.

Blocking suspend blockers

Posted May 21, 2010 12:57 UTC (Fri) by farnz (subscriber, #17727) [Link] (2 responses)

Close, but not quite for the HTC Hero running Android 1.5. When you download "cow bouncer" or "JTR Android", you get warned that the application can "Prevent the phone from sleeping", and have to say OK or Cancel to the "install anyway" prompt.

There's no in-built UI for catching bad apps, but there are third party applications in the Market that use the existing API to tell you which applications are using power - they're spotted not because they're CPU hogs, but because they're holding a wakelock preventing the phone from sleeping.

Blocking suspend blockers

Posted May 21, 2010 15:58 UTC (Fri) by Aissen (subscriber, #59976) [Link] (1 responses)

HTC Hero running Android 1.5

Although it was released just over a year ago, Android 1.5 is a pretty old in the Android timeline.
Wonderful things have happened, and three releases later Android 2.2 have been announced officially yesterday.
HTC promised to update the Hero to Android 2.1, and hopefully you'll get it sooner rather than later, and see the UI everyone's talking about in the default OS.

The most important is that susupend blockers are merged so that the future of Android is one where upstream matters, and Android kernel is no longer a fork.

Blocking suspend blockers

Posted May 21, 2010 16:00 UTC (Fri) by farnz (subscriber, #17727) [Link]

Android 1.5 is the latest version available for my device; I cannot in fairness tell you how Android behaves without qualifying it with the version number, because I can't tell you if it's been improved in later versions.

However, I'd hope that in this respect, Android isn't regressing in new versions. Power management is kinda critical on a phone.

Blocking suspend blockers

Posted May 21, 2010 23:17 UTC (Fri) by vonbrand (subscriber, #4458) [Link] (4 responses)

Ever heard of dancing pigs? Fat chance that the end user will ever make an informed decision on installing an application calling for this then...

Blocking suspend blockers

Posted May 22, 2010 1:53 UTC (Sat) by swetland (guest, #63414) [Link] (3 responses)

It is true that users are well-trained to keep clicking until they get whatever it is that they're after, but the way we use suspend blockers in Android includes more than just warning users that the app may "prevent the device from sleeping":

- Applications that don't specifically need to prevent suspend don't request the permission, and the vast majority of apps fall into that category. The user obtains benefit here in that if non-suspend-blocking apps perform poorly, they only do so while the device is awake, which we attempt to minimize.

- Applications that keep the device awake must use suspend blockers and the statistics from their use allows us to answer the "Why is my battery running low?" question by pointing out apps that are contributing to poor battery life. The "battery low, please plug in the charger" notification has had a "Why?" button since Android 2.0, to help users discover the "what apps are using up my battery" panel.

So yes, users will certainly get their dancing pigs (or bouncing cows), especially on a platform that has no restrictions on app installation, but we can certainly help the user still have a positive experience, or at the least, understand what the cause of their negative experience is.

Blocking suspend blockers

Posted May 22, 2010 2:30 UTC (Sat) by dlang (guest, #313) [Link] (2 responses)

do the statistics tell you how long an app has blocked suspend? how many times it's done so? what percentage of the time?

a long running app that uses suspend blockers only where needed could still show up as a top item for total time blocked or how many times it's blocked.

Blocking suspend blockers

Posted May 22, 2010 3:15 UTC (Sat) by swetland (guest, #63414) [Link] (1 responses)

The battery statistics service tracks number of times acquired, total realtime (aka walltime) held, etc. Here's a sample from a typical bugreport. The user facing UI is, of course, friendlier looking: http://frotz.net/misc/battery-stats-unplugged.txt

It starts with an overview then provides a UID-by-UID and process-by-process breakdown of wakelocks, cpu time, sensor usage, etc.

Blocking suspend blockers

Posted Jun 1, 2010 20:11 UTC (Tue) by Duncan (guest, #6647) [Link]

Thanks for the link to a real log. That's one thing I'd not seen in all this discussion.

Blocking suspend blockers

Posted May 20, 2010 12:17 UTC (Thu) by iq-0 (subscriber, #36655) [Link]

I'm probably missing some things, but in my view these "suspend blockers" are nothing more than a simple semaphore lock around the "deep suspend" resource. And as such it is nothing more than a very basic synchronization mechanism between a lot of concurrently running processes.

To put it differently: I don't think "suspend blockers" actually add something new, they just move the "device not ready for suspending" synchronized flag out of the driver and into the generic kernel. The "userspace can inhibit suspend" is nothing more than a N-th party acquiring the "lock".

This "lock" would logically be something very close to the device structure used for other stuff (thus the "system" cannot suspend, because a "bus" cannot suspend, because a "device" has the "suspend lock" but the rest can be suspended). So this would effectively be a hierarchical locking scheme where releasing the lock would switch that part of the hierarchy to the default idle state.

This default idle state would for normal (classic PM) probably be simply to let the device be turned on (or put in a shallow power state in laptop mode) and in the aggressive power-save state it would immediately put all resources in that subtree in a deeper power state.

Userspace could simply control this "wanted powerstate" attribute given external observation (how it's done now) and the "locking" would prevent the system from powering down devices that are in a critical region until they're done.

The tricky bits in suspend are normally the interdependencies between devices that are powered down and devices that want to power down. But the "aggressive power-save" state should still inhibit devices (or even wake them) when others really need them (a simple write to disk would probably have to wait, but a read is blocking someone).

There ofcourse always subtle behaviours to take care of, but the general idea of locking could possibly apply to simple suspend as well. And one doesn't really have to write code to put devices in as deep a sleep as possible but the rather easier: don't power down during this critical region.

Android looks good in that aera

Posted May 20, 2010 13:24 UTC (Thu) by xav (guest, #18536) [Link] (8 responses)

I have a N900 which, unlike Android, uses a more desktop-like system. It's a "normal" kernel where applications have to be careful not to drain the battery.
And believe me, even if it seems it's a good idea, it sucks for a phone. I often find my phone dead because some IM app just wakes up once every few seconds, which is nearly undetectable with top but is sufficient to avoid deep sleep and drains the battery like mad.

So, even if at first I found the concept of a desktop-like linux on a phone better, the more I learn about Android the more I think the latter made the right design decision.

Android looks good in that aera

Posted May 20, 2010 18:03 UTC (Thu) by dlang (guest, #313) [Link] (6 responses)

and if that IM app raises the blocker flag to prevent the system from going to sleep so that it can do it's checks, how are you any better off?

Android looks good in that aera

Posted May 20, 2010 18:13 UTC (Thu) by zlynx (guest, #2285) [Link] (2 responses)

Because suspend blocks are noisily pointed out to both the developer and the user.

While in the IM example, a desktop software developer might find it perfectly reasonable to wake every 5 seconds and not think anything of it.

Android looks good in that aera

Posted May 20, 2010 18:41 UTC (Thu) by felipebalbi (subscriber, #56613) [Link] (1 responses)

You don't need suspend blockers to shout that an app is preventing sleep or waking up too much, take a look at powertop http://www.lesswatts.org/projects/powertop/

Android looks good in that aera

Posted May 20, 2010 19:01 UTC (Thu) by zlynx (guest, #2285) [Link]

Another point.

With suspend blockers the developer must take action in order to keep the system awake by setting a suspend block on purpose.

Without suspend blockers the developer will keep the system awake by default just by writing normal software. The developer must take action, often quite a lot of code redesign, in order to *not* keep the system awake.

Android looks good in that aera

Posted May 20, 2010 18:25 UTC (Thu) by farnz (subscriber, #17727) [Link]

Suspend blockers would help in one or possibly two ways:

You can log whenever a suspend blocker is taken out or released, so it's then obvious that the IM app is causing the power draw; when it just wakes up briefly once a second to poll things, it vanishes in system noise. Even an in-memory log is enough to let you spot apps that are claiming a suspend blocker once a second.
Assuming you have appropriate system capabilities, you can prohibit the application from taking out the block in the first place. For example, you could set permissions that prevent the app from taking out a suspend block, or use a library to lie to the application and tell it that it has a block taken out when it doesn't.

Android looks good in that aera

Posted May 20, 2010 22:26 UTC (Thu) by iabervon (subscriber, #722) [Link] (1 responses)

IM applications never consider the possibility that the system could suspend. They are poor citizens because they don't think about the issues, not because they consider the issues and decide to be bad. This would mean that they wouldn't even consider the possibility that they could need or want a suspend blocker. And, on a system that uses suspend blockers, their naive design is fine: they check for updates every 5 seconds if the system is awake, but don't keep the system awake if there's nothing else keeping it awake.

In fact, the current situation doesn't really give IM applications the ability to behave well; they need to update is a reasonable amount of time without any user interaction if the user is watching the window out of the corner of their eye, but don't need to do anything if the user is actually not paying attention. There's no current easy way for an application to say "sleep for 5 seconds, but don't bother waking me if the user doesn't care", and applications just don't consider this situation anyway, so they don't tend to try to set up a negotiation with the screensaver or something.

Android looks good in that aera

Posted May 21, 2010 0:48 UTC (Fri) by brendan_wright (guest, #7376) [Link]

I've used a couple of Android devices as my main phone over the last two years. While their early JVM's were very inefficient and chewed through the power when you were actually using them (which has since been improved greatly), their ability to not suspend on you when you're playing music or using the nav software, but also not be "mysteriously dead" when you need to use them, is awesome!

I wish I could say the same about my Ubuntu powered laptops - they're either suspending on you 10 minutes into your movie because you left the power management switched on, or are unexpectedly dead when you need them because you switched it off. I'm hoping the merge of suspend blockers will improve this situation, as enable all the money that's being thrown at building Android powered phones, in-car devices, tablets etc to broaden the range of drivers compatible with the mainline Linux kernel.

Android looks good in that aera

Posted May 20, 2010 18:40 UTC (Thu) by felipebalbi (subscriber, #56613) [Link]

Badly written apps aren't the only problems in N900, due to a HW problem smartreflex (which is a technology to automatically adjust the regulators in the PMIC to save battery) can't be used.