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? 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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
