This week's episode of "Desperate Androids"

By Jonathan Corbet
June 7, 2010

In last week's episode of this particular soap opera, we described the criticism that blocked the merging of suspend blockers and the shape of a solution which was seemingly emerging from the ruins. But declaring an end to this particular story is always a hazardous thing to do. Now it looks like the suspend blocker discussion may last for another release cycle or two.

On June 4, Ingo Molnar posted a proposed solution which was a variant of the quality-of-service-based approach described last week. It looked feasible until Linus wandered into the discussion (for the first time), saying:

Quite frankly, this sounds fundamentally broken. Think deadlock. The high-latency task got a lock, and now you're excluding it because it scheduled away.

So the discussion started anew. Linus pushed for a solution which avoids the rest of the core kernel (and the scheduler in particular) as much as possible - a goal which the initial suspend blocker implementation shared. He also raised the issue of multi-core processors, which are not really addressed by the current code. There might be value in being able to shut down individual cores as the system load drops, suspending the system when there's nothing for the last CPU to do. One assumes that SMP handsets are not that far away, so planning for them would be a sensible thing to do.

All told, the situation has grown more complicated - but it also seems that the will to solve it has grown. It is becoming clear that the real solution may not show up in a hurry, though. So, in the meantime, we may see a stopgap solution which was first proposed early in the discussion: add stub versions of the suspend blocker API so that various Android drivers can be merged unchanged. That should help the mainline and Android kernels come much closer to convergence while allowing time for a globally acceptable solution to the suspend blocker problem to be solved. We will likely see those stubs merged, possibly with a 2.6.37 expiration date. The more contentious stuff will come some time after.

Index entries for this article
Kernel	Android

This week's episode of "Desperate Androids"

Posted Jun 10, 2010 11:05 UTC (Thu) by rvfh (guest, #31018) [Link] (2 responses)

> add stub versions of the suspend blocker API

Weird that one would choose to use the API and not the code... I would think that one wants to get right is the API, the code that's below can then be changed to anything one wants it to be (QoS, wavelock, etc..)

This week's episode of "Desperate Androids"

Posted Jun 10, 2010 12:35 UTC (Thu) by nix (subscriber, #2304) [Link]

The code's invasive, implements a new userspace ABI that the kernel folks aren't sure they want, and implements semantics that aren't actually useful on hardware that can't suspend as fast as Android (i.e. nearly everything).

At least with stubs the Android *drivers* can go in without pervasive changes.

This week's episode of "Desperate Androids"

Posted Jun 10, 2010 17:53 UTC (Thu) by iabervon (subscriber, #722) [Link]

The API for a driver to say "I've started something that needs to finish before the system can be considered idle enough to suspend" and "This thing is done now" should be pretty obvious. Even if some sort of QoS thing turns to be the real API, the above is still going to be a common enough case to justify having a helper rather than making everybody open-code the necessary QoS-setting call.

Of course, if the kernel lacks a mode where the system suspends because it is idle, the implementation is uncontentious: the kernel doesn't need to do anything when drivers call those functions. So Android drivers would be able to act to keep the kernel from autosuspending at a bad time, because a mainline kernel doesn't autosuspend ever and a kernel with autosuspension does something real with those functions.