Suspend blocker suspense [LWN.net]

By Jonathan Corbet
May 26, 2010

As of last week's article on the Android suspend blocker mechanism, the conversation appeared to be slowing down. Such blessings, it seems, are never permanent; many electrons have been perturbed to continue this discussion since then. The end result is that the late entrance into the discussion by people with names like Alan Cox, Thomas Gleixner, and Peter Zijlstra has made the merging of this feature more unlikely.

Alan's dissent was arguably the most coherent and constructive of just about any that have been posted thus far. He thinks that the problem being addressed by suspend blockers (misbehaving applications) is real, but the solution is wrong. He suggests, instead, the addition of a setpidle() system call which indicates the extent to which a process can prevent the system from going into an idle state. If the process is running an untrusted application, the system would be able to go idle (or suspend) even if that process is runnable at the time. More trusted processes (the ones which would be able to use suspend blockers in the Android scheme) would have a higher priority and would be able to run at any time.

The other piece of the solution, according to Alan, is to put pressure on the authors of badly-written applications. Thomas agrees:

We have already proven that the social pressure on crappy applications works. When NOHZ was merged into the kernel we got no effect at all because a big percentage of user space applications just used timers at will and without any thoughts, also it unveiled busy polling and other horrible coding constructs. So what happened ? Arjan created powertop which lets the user analyse the worst offenders in his system. As a result the offending apps got fixed rapidly simply because no maintainer wanted to be on top of the powertop sh*tlist.

A number of developers have expressed the fear that trying to mitigate the impact of badly-written applications in the kernel will only serve to take the pressure off developers, leading to more bad applications over time.

Meanwhile, Rafael Wysocki has sent a pull request for suspend blockers to Linus, saying:

Some alternative approaches have been proposed during the on-going discussion, but they are general ideas rather than specific technical propositions, and until someone actually tries to implement them it's not really known whether or not they are suitable for Android. For this reason I don't think we can realistically expect Google to implement any of them. Thus, in my view, we have a choice to either accept or reject this feature altogether.

As of this writing, Linus has not said what he intends to do. Given the way the conversation has gone, though, it would not be surprising to see the merge window end with no suspend blockers in the mainline. Merging a user-visible feature like suspend blockers is a move which cannot be undone after the 2.6.35 release; when there is this much disagreement, letting another development cycle go by may seem like the prudent thing to do.

(Log in to post comments)

Suspend blocker suspense

Posted May 27, 2010 8:46 UTC (Thu) by neilbrown (subscriber, #359) [Link]

There seem to be a few different issues here that get conflated and so
confuse the picture. I think I can pick out three things.

The context is, of course, that we want to get to a low power state as
quickly as possible, but lower power states tend to have larger
latencies for resuming operation and that can sometimes be a problem.

So the three issues are:

1/ Some application may "know" that it needs low latency. i.e. it is
busy doing something useful for the device owner and shouldn't be
forced into an unduly low power state. Thus it will want to "block
suspend".

2/ An event may arrive (incoming call, button press, etc) at the
kernel level, and the kernel needs to ensure that this event gets
adequately responded to before we drop into a low power state.
e.g. for an incoming call, the kernel needs to keep the phone from
suspending until the gui has had a chance to notice the call and so
request it's own suspend-block.

3/ Maybe we shouldn't be suspending anyway. If any process is active,
then it should be able to run. Hardware should (and supposedly new
hardware does) use as little power if a non-suspend deep sleep as it
does in full suspend so there should be no need for suspend.
I'm not sure I have that argument exactly right. Maybe suspend is OK
if we "know" that any important interrupt will wake from suspend, and
that we "know" how long to the next timer event and can program a
wakeup for that time.

The "suspend blocker" proposal seems to conflate the first two and
adds the assumption that the required minimum latency that an app can
ask for is either all or nothing. It ignores the third, or maybe
explicitly disagrees with it, saying that processes have no right to
expect to keep running unless they explicitly ask for (and pay for)
that right.

On top of that there are subtleties about how an app might express its
latency requirements, whether it might be just another ulimit or
whether something else might be needed.

So on the whole I'm not surprised that the discussion isn't getting
anywhere as you can always find one part of the big complex issue that
a particular proposal doesn't address, and attack it on that basis.

I think it is important to clearly define the problem first (didn't
Einstein say that?) and in this case I think we have several problems
that need to be separated - quite probably more than just these three.

Suspend blocker suspense

Posted May 27, 2010 17:56 UTC (Thu) by talisein (subscriber, #31829) [Link]

It seems to me for opportunistic suspend to fit into the larger Linux ecosystem, "blocking suspend" should not be an opt-in activity but rather an opt-out.

By default, applications expect to run. If they are feeling nice, they should be able to declare to the kernel "There is some work I'd like to do, but its okay if you ignore me if you think its a good time to suspend."

Then we don't have paranoid people adding blockers all over the kernel and device tree; instead people will look for places where it is explicitly okay to unblock suspend. Meanwhile Android can implement the opt-in in their base classes, while Wakelocks become inverted. This also has the benefit of publishing an interface that desktop distros can leave enabled, and GNOME/KDE/everyone else can slowly identify the non-critical sections of their code.

Suspend blocker suspense

Posted May 29, 2010 21:44 UTC (Sat) by jrn (subscriber, #64214) [Link]

> By default, applications expect to run. If they are feeling nice, they should be able to declare to the kernel "There is some work I'd like to do, but its okay if you ignore me if you think its a good time to suspend."

The parent can take a suspend block and provide an interface for its children to request to relinquish it. Consider the result: what happens in the window after each child is spawned and before it makes that request? If a shell script spawns friendly processes in its inner loop, is that going to block suspend?

Extending the block-by-default behavior to drivers would make it even worse. Every driver would need to include code to stop blocking suspend or the author would receive angry complaints that it killed the ability to suspend.

If I understand correctly, suspend blockers affect both opportunistic suspend and deliberate requests by the user to suspend.