Re: Attempted summary of suspend-blockers LKML thread
From: Paul E. McKenney
Date: Tue Aug 03 2010 - 21:09:20 EST
On Tue, Aug 03, 2010 at 03:23:00PM -0700, Arve Hjønnevåg wrote:
> 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.
Ah, good to know!
> >> > 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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/