Messages in this thread | | | Date | Tue, 18 May 2010 17:00:21 -0700 | Subject | Re: [PATCH 0/8] Suspend block api (version 7) | From | Arve Hjønnevåg <> |
| |
2010/5/18 Kevin Hilman <khilman@deeprootsystems.com>: > Arve Hjønnevåg <arve@android.com> writes: > >> >> PM: Opportunistic suspend support. >> >> Power management features present in the current mainline kernel are >> insufficient to get maximum possible energy savings on some platforms, >> such as Android, because low power states can only safely be entered >> from idle. Suspend, in its current form, cannot be used, since wakeup >> events that occur right after initiating suspend will not be processed >> until another possibly unrelated event wake up the system again. > > I think the problems with wakeups in the current suspend path need to > be described in more detail. In particular, why check_wakeup_irqs() > is not enough etc. >
check_wakeup_irqs only handles interrupts that occurred after the interrupt was masked during suspend. If the interrupt occurred before it was masked, it will not be pending when check_wakeup_irqs is called.
>> On some systems idle combined with runtime PM can enter the same power >> state as suspend, but periodic wakeups increase the average power >> consumption. Suspending the system also reduces the harm caused by >> apps that never go idle. On other systems suspend can enter a much >> lower power state than idle. >> >> To allow Android and similar platforms to save more energy than they >> currently can save using the mainline kernel, we introduce a mechanism >> by which the system is automatically suspended (i.e. put into a >> system-wide sleep state) whenever it's not doing useful work, called >> opportunistic suspend. > > A definition of "useful work" here would provide clarity and would > also help clarify by what criteria other on-going work is determined > to be not useful. > > Kevin >
-- Arve Hjønnevåg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |