Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

["Rafael J. Wysocki" <rjw@rjwysocki.net>]

[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]

On Friday, July 31, 2015 06:55:47 PM Mark Brown wrote:
> On Thu, Jul 30, 2015 at 02:57:17AM +0200, Rafael J. Wysocki wrote:
> 
> > Essentially, what happens is that runtime PM allows us to reach the state
> > in which the system draws as little power as in suspend-to-idle, but it
> > simply doesn't allow the system to stay in that state long enough in one
> > go due to timer interrupts (and possibly other types of interrupt noice
> > that is suppressed by suspending all devices).
> 
> > Since energy is the power drawn in a given state times the time spent in that
> > state (on the average), that's why the system in suspend-to-idle uses less
> > energy than it would with runtime idle during the same period (modulo the
> > energy spent on suspending and resuming devices etc, of course).
> 
> We could in theory work to reduce the number of these additional timer
> and other interrupts further - there was a lot of focus on this in the
> past (partly for desktop use cases where suspend isn't such a quick out)
> though with the advent of Android and the wide deployment of suspend to
> idle that resulted people stopped bothering on the embedded side since
> suspend to idle is both simple and effective.

In addition to that, while we can reduce the number of those in the kernel,
user space can still do things that increase the number of them and we can't
really control it.  That only depends on what applications are running and
users may not be aware of all of the consequences of running them.

By freezing user space during suspend we effectively prevent it from
scheduling more timer events in the future.

Thanks,
Rafael

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]