Re: Attempted summary of suspend-blockers LKML thread

On Tue, Aug 03, 2010 at 03:23:00PM -0700, Arve Hjønnevåg wrote:

2010/8/3 Paul E. McKenney [off-list ref]:

quoted

On Mon, Aug 02, 2010 at 09:18:27PM -0700, Arve Hjønnevåg wrote:

quoted

On Sat, Jul 31, 2010 at 10:58 AM, Paul E. McKenney
[off-list ref] wrote:

...

quoted

quoted

quoted

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

...

quoted

quoted

quoted

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.

quoted

Or am I missing some other subtlety?

No.

...

quoted

quoted

quoted

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