From mboxrd@z Thu Jan 1 00:00:00 1970 From: mark gross Subject: Re: [RFC][PATCH 0/9] Suspend block api (version 3) Date: Fri, 8 May 2009 09:01:46 -0700 Message-ID: <20090508160146.GA22750@linux.intel.com> References: <1241583529-5092-1-git-send-email-arve@android.com> <873abixiam.fsf@deeprootsystems.com> Reply-To: mgross@linux.intel.com Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-pm-bounces@lists.linux-foundation.org Errors-To: linux-pm-bounces@lists.linux-foundation.org To: Arve =?iso-8859-1?B?SGr4bm5lduVn?= Cc: swetland@google.com, linux-pm@lists.linux-foundation.org, u.luckas@road.de, ncunningham@crca.org.au List-Id: linux-pm@vger.kernel.org On Thu, May 07, 2009 at 03:42:27PM -0700, Arve Hj=F8nnev=E5g wrote: > 2009/5/6 Kevin Hilman : > > Arve Hj=F8nnev=E5g writes: > > > >> This patch series adds a suspend-block api that provides the same > >> functionality as the android wakelock api. This patch series removes > >> the sysdev that was used to abort suspend and adds a direct check in > >> suspend_enter instead. It also has some other code style changes. > > > > Sorry for joining the wakelock/suspend-block discussion a bit late, > > but I have a very basic, and possibly stupid question on the need for > > such a feature. > > > > My basic question: is why not use idle (dynamic PM) instead of suspend > > (static PM) for this? > > > = > We use suspend in addition to idle, not instead of. On some systems > (msm) we can enter the same power state from idle as from suspend. > This reduces the importance of suspend, but entering suspend still has > benefits. The monotonic clock stops and all the periodic timers > (user-space and kernel) that are based on it stop with it. It also > reduces the amount of energy an untrusted application can waste since > it will not be allowed to run when the system is suspended. Yes CPUIDLE and pmqos are more "cooperative" power management, where suspend is a preemptive form of PM. I get a little itchy when the preemptive PM is made automatic from the kernel level. BTW Thanks. I feel like I'm understanding your PM design a bit better now. --mgross > = > > IOW, why not use CPUidle + PM QoS to achieve the same goal? =A0It seems > > to me that you're trying to add some dynamic PM features onto a static > > PM subsystem. =A0I could see PM QoS possibly needing some extending but > > the basic abilities to constrain the low-power states are there. > = > suspend blockers have no impact on this. > = > > The one reason I can think of is that you can always have broken > > drivers or apps that prevent you from hitting idle. =A0But with tools > > like powertop, it's pretty easy to find these problems and fix them. > > > Tools allow you to find apps that waste power, but they do not fix them. > = > > If that is the primary concern, it seems to me that we're introducing > > a new kernel API to work around broken drivers and apps that should be > > fixed instead. > > > > What am I missing? > = > Suspend blockers allow you to use suspend. On platforms that cannot > enter the same power state from idle this is essential. On platforms > can enter the same power state from idle as suspend, suspend reduce > the time spent running which in turn reduces the overall power draw. > It also offers some protection against bad apps which is important on > an open device. > = > -- = > Arve Hj=F8nnev=E5g > _______________________________________________ > linux-pm mailing list > linux-pm@lists.linux-foundation.org > https://lists.linux-foundation.org/mailman/listinfo/linux-pm