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

mark gross
2009-05-08T16:01:46Z

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