| |||||||||||||
Wakelocks and the embedded PMWakelocks and the embedded PMPosted Feb 12, 2009 18:00 UTC (Thu) by mgross (subscriber, #38112)Parent article: Wakelocks and the embedded problem
As I look more and more closely at the wakelock structure I'm struck by how similar it is to some ideas we tossed around on the CELF PM working group a few years back. Ideas that fizzled a little at that time.
The high level notion of having a "fall-line" to low power states subject to constraints keeping components from "falling' to a lower power state is still quite interesting. FWIW at the time we worked on this concept in CELF things got complex around the dependency and notification networks that needed to be managed to make things work.
Wakelock implements a type of constraint method. I think the API has problems but the general idea of of constraint based steepest descent PM still has appeal. To me anyway.
(Log in to post comments)
Wakelocks and the embedded PM Posted Feb 13, 2009 0:53 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
I think the real question is over how constraints should be exposed. I'm very much on the side of inferring constraints from the behaviour of userland - if they have a device open then we should assume that they want to use it, so should avoid shutting it down. We're nowhere near providing that level of functionality in the kernel yet, but doing so helps the embedded, desktop and server worlds.
I'm not sold on the idea of providing explicit constraints in most cases. If you're going to provide that constraint explicitly, why not allow the kernel to infer it? The code to say "Nothing needs access to input devices now" is not significantly differently complicated to the code that closes the input device when it doesn't need it. But that's the kind of case that the Android code deals with now.
Stuff like the pm_qos framework deals with a different case, where you're supplying additional functional constraints to the kernel above and beyond those that can be inferred. I think we should be focusing on what those constraints might be rather than thinking about the wakelock and early suspend code from Android.
|
|||||||||||||