Re: [PATCH 0/8] Suspend block api (version 6)

[mark gross <mgross@linux.intel.com>]

On Mon, May 03, 2010 at 09:40:26AM -0700, Kevin Hilman wrote:
> Arve Hjønnevåg <arve@android.com> 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. 

--mgross

> 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