Re: Attempted summary of suspend-blockers LKML thread

From: Arve Hjønnevåg
Date: Tue Aug 03 2010 - 18:23:10 EST

2010/8/3 Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>:
> 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@xxxxxxxxxxxxxxxxxx> 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.

>> > 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?


> Or am I missing some other subtlety?


>> > 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?


Arve Hjønnevåg
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at