[lkml]   [2010]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/8] Suspend block api (version 6)
On Mon, May 03, 2010 at 09:40:26AM -0700, Kevin Hilman wrote:
> Arve Hjønnevåg <> 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.

I also think we need to take a hard look at the process here.


> 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]
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2010-05-05 22:39    [W:0.387 / U:14.136 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site