Arve Hjønnevåg <arve@xxxxxxxxxxx> writes: > This patch series adds a suspend-block api that provides the same > functionality as the android wakelock api. This version fixes a race > in suspend blocking work, has some documentation changes and > opportunistic suspend now uses the same workqueue as runtime pm. Earlier this month, several folks intersted in embedded PM had a BoF as part of the Embedded Linux Conference[1] in San Francisco. Many of us had concerns about wakelocks/suspend-blockers and I wanted to share some of mine here, since I don't know if embedded folks (other than Google) were included in discussions during the LF Collab summmit. I hope other embedded folks will chime in here as well. My background is in embedded as one of the kernel developers on the TI OMAP SoCs, and I work primarily on PM stuff. My comments are not about this implementation of suspend blockers in particular, but rather on the potential implications of suspend blockers in general. Sorry for the lengthy mail, it's broken up in to 3 parts: - suspend blockers vs. runtime PM - how to handle PM aware drivers? - what about dumb or untrusted apps Suspend blockers vs runtime PM ------------------------------ My primary concern is that suspend blockers attempt to address the same problem(s) as runtime PM, but with a very different approach. Suspend blockers use one very large hammer whereas runtime PM hands out many little hammers. Since I believe power management to be a problem of many little nails, I think many little hammers are better suited for the job. Currently in the kernel, we have two main forms of PM - static PM (system PM, traditional suspend/resume etc.) - dynamic PM (runtime PM, CPUfreq, CPUidle, etc.) And with the addition of suspend blockers we have something in between. In my simple world, I think of suspend_blockers as static PM with a retrofit of some basic dynamic capabilities. In my view, a poor man's dynamic PM. The current design of suspend blockers was (presumably) taken due to major limitations and/or problems in dynamic PM when it was designed. However, since then, some very signifcant improvements in dynamic PM have come along, particularily in the form of runtime PM. What I still feel is missing from this discussion are details about why the issues addressed by suspend blockers cannot be solved with runtime PM. It seems to me the keypad/screen example given in the doc can very easily be solved with runtime PM. The goal of that example is that the keypad not turn on the screen unless a specific key is pressed. That is rather easy to accomplish using runtime PM: 1. system is idle, all devices/drivers runtime suspended (display and keypad drivers are both runtime suspended) - keypress triggers wakeup ->runtime_resume() of keypad (screen is still runtime suspended) - key press trickles up to userspace - keypad driver is done, goes idle and is runtime supended - userspace decides whether or not to turn on screen based on key - if not, goto 1, (display is still runtime suspended) - if so, start using display and it will be runtime resumed I realize this keypad example was only one example usage of suspend blockers, but I suspect the others would be solved similarily using runtime PM. But anyways, to get back to the main point: I feel the main problems tackled by _kernel_ suspend blockers (as I understand them) are the same problems already addressed by runtime PM. First and formost, both have the same guiding principle: Rule #1: Always try for lowest power state, unless X For runtime PM, X = "activity" For suspend blockers, X = a held suspend_blocker In addition, both have the same secondary goals: - keep device PM independent of other devices (e.g. don't wake up screen just because keypad was pressed) - wakeups/events can be handled in a device specific way, without affecting other devices or rest of the system, unless desired So, the goals are the same, but the approaches are different. Runtime PM makes each of the drivers and subsystems do the work, where suspend blockers just forces the issue from on high. IMHO, the more flexible and generic approach of runtime PM is more suited to a general purpose kernel than the one-big-hammer approach currently taken by suspend blockers. What about PM aware drivers? ---------------------------- All of this brings up a second major concern regarding how to write PM aware drivers. At least from the kernel perspective, both suspend blockers and runtime PM have the same goal. Given that, which framework should the driver writer target? Both? Seems like duplicate effort. Using suspend blockers assumes the system is in opportunitstic suspend mode and (at least in the keypad example given) assumes a suspend-blocker aware userspace (Android.) Without both, targeted power savings will not be acheived. To me, runtime PM is a generic and flexible approach that can be used with any userspace. Driver writers should not have to care whether the system is in "opportunistic" mode or about whether userspace is suspend blocker capable. They should only have to think about when the device is (or should be) idle. >From my experience with OMAP, we *really* do not want to care about what userspace is or isn't capable of, or what suspend-mode the kernel is in. Among other things, the OMAP linux kernel is used in the Nokia N900 (Maemo), the Motorola Droid (Android) and the Palm Pre (webOS). Comments on the future of each SW stack aside, we really want to run the same kernel and drivers across all of those platforms as well as whatever comes next. What about dumb or untrusted apps? --------------------------------------- In my view, the truly significant difference between suspend blockers and runtime PM is what happens to userspace. So far, to me the only compelling argument for suspend blockers is the goal of forcibly shutting down userspace and thus forcing the system into idle (although drivers could still reject a suspend request.) Again, since suspend blockers were designed, there have been major efforts to track and fix userspace as well as underlying timer issues (deferrable timers, coalescing, timer slack ...) that led to unnecessary wakeups from userspace. Wouldn't it be better to spend our collective efforts in continuing in that direction instead of just hiding the underlying problems by forcing suspend? Fixing the root causes will be better for everyone, not just those using Android. And if untrusted userspace apps remain as the major problem, maybe we should aim for a solution directly targetting that problem. I'm just shooting from the hip now, but maybe containing (cgroups?) untrusted processes together into a set that could be frozen/idled so that runtime PM would be more effective would be a workable solution? Anyways, that's enough rambling for now. I hope that sheds some light on the concerns I have with suspend blockers. Kevin [1] http://embeddedlinuxconference.com/elc_2010/index.html _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
