User: Password:
Subscribe / Log in / New account

A new approach to opportunistic suspend

A new approach to opportunistic suspend

Posted Sep 29, 2011 22:41 UTC (Thu) by neilbrown (subscriber, #359)
In reply to: A new approach to opportunistic suspend by khim
Parent article: A new approach to opportunistic suspend

Bah. The use cases are perfectly clear.
And (with one small caveat) the Android API is perfectly sane and simple to implement on todays mainline kernel (baring bugs due to lack of testing).

The small caveat is what does "CPU" mean in the context of things that can be "on" or "off".

The Android interpretation means "CPU is off" is when system is "suspended" and "CPU is on" is when system is not suspended. Among other things, "suspend" defines a class of events which can wake from suspend. All other events will not.
So we could re-describe "CPU is off" as "only class X of events will be responded to" while "CPU is on" is "all events will be responded to". Because a process could be CPU-bound, we might need to interpret the completion of one CPU instruction as an event which triggers the execution of the next CPU instruction. These events are ignored during suspend.

The school of thought to which Peter Z seems to belong is essentially saying that this classification of events is too coarse because

a/ modern hardware often has a lot more control of power states and can save the same power without flushing all registers and stopping all clocks and going fully into suspend. So an application should get a wakelock on the events it really wants rather than on the class X of events called "CPU".

b/ Badly behaved applications can still waste power even without being able to take wakelocks. If one app is holding a CPU wakelock, then any app is allowed to use the CPU and waste power.

'b' touches the monitoring side of wakelocks rather than the locking side. wakelocks allow the system to know who is keeping the device awake to know who to blame. But we really want to know who is keeping the CPU busy and so wasting power. So I think the suggestion is that rather than making the CPU available to all processes, or not, the system should count the cycles used by each process and charge accordingly. So if any process wants to execute instructions it shouldn't need a wake-lock, it should just execute them, but be charged. It might still need a wake-lock on any events it wants like timers or frame-refresh signals or keyboard or whatever. An app which shows a high battery-use charge is likely to be quickly uninstalled.

So if the hardware were capable of very low power idle, and of accounting CPU cycles to processes, then taking the "execute next instruction" event out of the set of events tied to "CPU is on", and charging for it explicitly would probably make a lot of sense, and wouldn't need a change in the API.

(Log in to post comments)

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds