Blocking suspend blockers

Posted May 20, 2010 4:44 UTC (Thu) by wblew (subscriber, #39088)
In reply to: Blocking suspend blockers by dlang
Parent article: Blocking suspend blockers

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.

to post comments

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.