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
