Re: [RFC][PATCH 0/9] Suspend block api (version 3)

From: mark gross <mgross@linux.intel.com>
To: "Arve Hjønnevåg" <arve@android.com>
Cc: swetland@google.com, linux-pm@lists.linux-foundation.org,
	u.luckas@road.de, ncunningham@crca.org.au
Subject: Re: [RFC][PATCH 0/9] Suspend block api (version 3)
Date: Fri, 8 May 2009 09:01:46 -0700	[thread overview]
Message-ID: <20090508160146.GA22750@linux.intel.com> (raw)
In-Reply-To: <d6200be20905071542k6810b817idf2a07dc55665324@mail.gmail.com>

On Thu, May 07, 2009 at 03:42:27PM -0700, Arve Hjønnevåg wrote:
> 2009/5/6 Kevin Hilman <khilman@deeprootsystems.com>:
> > Arve Hjønnevåg <arve@android.com> 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?  It seems
> > to me that you're trying to add some dynamic PM features onto a static
> > PM subsystem.  I 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.  But 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ønnevåg
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm