| |||||||||||||
A new approach to opportunistic suspendA new approach to opportunistic suspendPosted Sep 29, 2011 13:58 UTC (Thu) by khim (subscriber, #9252)In reply to: A new approach to opportunistic suspend by kiko Parent article: A new approach to opportunistic suspend
After all this time, are the use cases this tries to address not clear? Of course not! That's the problem. Maybe we should fix that first. Not possible. Period. That's the problem with userspace APIs: they are used to implement all kind of functionality not ever imagined by their developers. This is the same with wakelocks: they were initially created to solve problems of a few concrete examples. But since they were available people started using them for all kinds of other stuff (remember that they are available in official Android API). Thus today if you want to rip them out you'll need to either implement identical functionality (and then we can only talk about clean interface between kernel and userpsace) or you should support all the usecases hundred of thousand of apps out there are presenting.
(Log in to post comments)
A new approach to opportunistic suspend Posted Sep 29, 2011 16:04 UTC (Thu) by kiko (subscriber, #69905) [Link]
How can it not be possible to provide a compelling subset of the existing use cases?
At any rate, you have a valid point that what we are arguing here is for a capability that has the potential of addressing a major class of problem that application developers face. Perhaps better than outlining the use cases individually might be describing the class of problems wakelocks let you address. I think Paul McKenney actually tried this a while back, but it rambled on too much -- but maybe John has the guts to run a more focused thread on the subject.
Alternatively, we could motivate the kernel community into appreciating that while they don't see the feature addressing their own use cases, a population of Android application developers are relying on the functionality, and it would be the responsible thing to either support them or convert them to use something else.
A new approach to opportunistic suspend Posted Sep 29, 2011 20:23 UTC (Thu) by jrn (subscriber, #64214) [Link]
> Alternatively, we could motivate the kernel community into appreciating that while they don't see the feature addressing their own use cases, [...]
The usual approach in that case is for people who do see value in the feature to join the kernel community. Hard work, but possible.
A new approach to opportunistic suspend Posted Sep 29, 2011 22:41 UTC (Thu) by neilbrown (subscriber, #359) [Link]
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.
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.
|
|||||||||||||