Re: Attempted summary of suspend-blockers LKML thread

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Tue, Aug 03, 2010 at 03:23:00PM -0700, Arve Hjønnevåg wrote:
> 2010/8/3 Paul E. McKenney <paulmck@linux.vnet.ibm.com>:
> > On Mon, Aug 02, 2010 at 09:18:27PM -0700, Arve Hjønnevåg wrote:
> >> On Sat, Jul 31, 2010 at 10:58 AM, Paul E. McKenney
> >> <paulmck@linux.vnet.ibm.com> wrote:
> ...
> >> > o       Statistics of the power-control actions taken by power-aware
> >> >        applications must be provided, and must be keyed off of program
> >> >        name.
> >>
> >> We don't key the stats off the program name, but having useful
> >> statistics is critical too us. The current code in linux-next does not
> >> appear to allow this (I'm referring to pm_stay_awake here, etc not
> >> pm-qos.)
> >
> > OK, maybe I was confused earlier.  So you do not track statistics via
> > the device being open throughout the application's lifetime?
> 
> The suspend blocker patchset does track statistics while the device is
> open, but it it not keyed of the program name. The name is passed from
> user-space and a single process can have the device open several
> times. The wakelock interface that we currently use just creates a new
> object every time it sees a new name and never frees it.

Ah, good to know!

							Thanx, Paul

> ...
> >> > o       If no power-aware or power-optimized application are indicating
> >> >        a need for the system to remain operating, the system is permitted
> >> >        (even encouraged!) to suspend all execution, even if power-naive
> >> >        applications are runnable.  (This requirement did appear to be
> >> >        somewhat controversial.)
> >>
> >> I would say it should suspend even if power aware applications are
> >> runnable. Most applications do not exclusively perform critical work.
> >
> > The point being that a power-aware application does not block suspend
> > -unless- it holds a suspend blocker, correct?
> 
> Yes.
> 
> >
> > Or am I missing some other subtlety?
> 
> No.
> 
> ...
> >> > o       Any initialization of the API that controls the system power
> >> >        state must be unconditional, so as to be free from failure.
> >> >        (I don't currently understand how this relates, probably due to
> >> >        my current insufficient understanding of the proposed patch set.)
> >>
> >> Unconditional initialization makes it easier to add suspend blockers
> >> to existing kernel code since you don't have to add new failure exit
> >> paths. It is not a strong requirement.
> >
> > Ah, that makes more sense!  I moved this to a new "NICE-TO-HAVES"
> > section.  I also changed the last parenthesized sentence to read
> > "Such unconditional initialization reduces the intrusiveness of the
> > the Android patchset."  Does that work?
> >
> 
> Sure.
> 
> 
> 
> -- 
> Arve Hjønnevåg