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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 07, 2009 at 03:42:27PM -0700, Arve Hjønnevåg wrote:
> 2009/5/6 Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx>:
> > Arve Hjønnevåg <arve@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxx
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux