- Mar 18, 2012
Please be patient with me guys this thread is work in progress...Many thanks to ahalford and with reading and learning from our great kernel devs here i will build this thread up as we go along
Right first up this thread is work in progress. Most of the info is from ahalford. He has been kind enough for me to use the information on his thread and share it here with you guys. Now to start with i will be sharing his info here and then i will be adding my own information as i go along with this thread as i am still learning and i feel i can add my own input here to...So enough of this and lets get going with the thread
What is wakelock and why it may cause battery drain:
Wakelocks or to be more precise partial wakelocks is a pattern (in fact a class) than helps devs to make sure that important pieces of their code do not get interrupted.
Basically the phone has (simplified, kernel devs don't shoot) three states:
1. awake with screen on
3. sleeping (that's you phone favorite state)
The transitions are from (1) to (2) and finally from (2) to (3). Now as long as you use your phone it's in (1) and does not leave that state as long as you keep using it interactively. If you stop using it the phone is aiming to go to (3) as fast as possible.
And here's where wakelocks are important: as our phones as smartphones they tend to do background processing. Some of this processing is important like e.g. making a phone call, listening to music or synchronizing your contacts.
As the phone wants to go from (2) to (3) and on the other hand you don't want to hang up while you are in a call the app keeps hold of a wakelock to prevent that transition. When you hang up the partial wakelock gets release and here we go (the phone goes to sleep).
So partial wakelocks is a tool and it's not something that we should forbid for obvious reasons. Now there are cases when the design on an app is not real life proven (conditions of poor of no coverage) and the wakelocks have negative effects because they are held unnecessarily or for too long.
How can we identify it?
BetterBatteryStats app identifies these wakelocks and using your expertise or the once from our users here you can understand what happens and find a strategy to change that for the better.
Link for BetterBatteryStats:
New app as well other than BBS is Wakelock Detector..
Link: WakeLock Detector - XDA thread
With this app you can detect applications which are consuming much battery by checking wakelock history.
It simplifies BetterBatteryStats by concentrating more on wakelocks.
No any background services or system bootup events for gathering data.
Brief explanation, about where to look at the wakelocks:
- Set your reference as "Since unplugged" in the second line.
- Then, in the first line: "Other" - look at the "Awake" vs "Screen on". If it differs a lot, continue with a drill-down.
- First line - check under "Partial Wakelocks" and "Kernel wakelocks".
- "Menu" - "More" - "Raw kernel wakelocks"
- For more help: "Menu" - "Help" - "Getting started" or "How to".
Brief History Lesson
The relationship between embedded system developers and the kernel community is known for being rough, at best. Kernel developers complain about low-quality work and a lack of contributions from the embedded side; the embedded developers, when they say anything at all, express frustrations that the kernel development process does not really keep their needs in mind. A current discussion involving developers from the Android project gives some insight into where this disconnect comes from.
Android, of course, is Google's platform for mobile telephones. The initial Android stack was developed behind closed doors; the code only made it out into the world when the first deployments were already in the works. The Android developers have done a lot of kernel work, but very little code has made made the journey into the mainline. The code which has been merged all went into the staging tree without a whole lot of initiative from the Android side. Now, though, Android developer Arve Hjønnevåg is making an effort to merge a piece of that project's infrastructure through the normal process. It is not proving to be an easy ride.
The most controversial bit of code is a feature known as "wakelocks." In Android-speak, a "wakelock" is a mechanism which can prevent the system from going into a low-power state. In brief, kernel code can set up a wakelock with something like this:
wake_lock_init(struct wakelock *lock, int type, const char *name);
The type value describes what kind of wakelock this is; name gives it a name which can be seen in /proc/wakelocks. There are two possibilities for the type: WAKE_LOCK_SUSPEND prevents the system from suspending, while WAKE_LOCK_IDLE prevents going into a low-power idle state which may increase response times. The API for acquiring and releasing these locks is:
void wake_lock(struct wake_lock *lock); void wake_lock_timeout(struct wake_lock *lock, long timeout); void wake_unlock(struct wake_lock *lock);
This submission has not been received particularly well. It has, instead, drawn comments like this from Ben Herrenschmidt:
looks to me like some people hacked up some ad-hoc trick for their own local need without instead trying to figure out how to fit things with the existing infrastructure (or possibly propose changes to the existing infrastructure to fit their needs).
or this one from Pavel Machek:
Ok, I think that this wakelock stuff is in "can't be used properly" area on Rusty's scale of nasty interfaces.
There's no end of reasons to dislike this interface. Much of it duplicates the existing pm_qos (quality of service) API; it seems that pm_qos does not meet Android's needs, but it also seems that no effort was made to fix the problems. The scheme seems over-engineered when all that is really needed is a "do not suspend" flag - or, at most, a counter. The patches disable the existing /sys/power/state interface, which does not play well with wakelocks. There is no way to recover if a user-space process exits while holding a wakelock. The default behavior for the system is to suspend, even if a process is running; keeping a system awake may involve a chain of wakelocks obtained by various software components. And so on.
The end result is that this code will not make it into the mainline kernel. But it has been shipped on large numbers of G1 phones, with many more yet to go. So users of all those phones will be using out-of-tree code which will not be merged, at least not in anything like its current form. Any applications which depend on the wakelock sysfs interface will break if that interface is brought up to proper standards. It's a bit of a mess, but it is a very typical mess for the embedded systems community. Embedded developers operate under a set of constraints which makes proper kernel development hard. For example:
One of the core rules of kernel development is "post early and often." Code which is developed behind closed doors gets no feedback from the development community, so it can easily follow a blind path for a long time. But embedded system vendors rarely want to let the world know about what they are doing before the product is ready to ship; they hope, instead, to keep their competitors in the dark for as long as possible. So posting early is rarely seen as an option.
Another fundamental rule is "upstream first": code goes into the mainline before being shipped to customers. Once again, even if an embedded vendor wants to send code into the mainline, they rarely want to begin that process before the product ships. So embedded kernels are shipped containing out-of-tree code which almost certainly has a number of problems, unsupportable APIs, and more.
Kernel developers are expected to work with the goal of improving the kernel for everybody. Embedded developers, instead, are generally solving a highly-specific problem under tight time constraints. So they do not think about, for example, extending the existing quality-of-service API to meet their needs; instead, they bash out something which is quick, dirty, and not subject to upstream review.
One could argue that Google has the time, resources, and in-house kernel development knowledge to avoid all of these problems and do things right. Instead, we have been treated to a fairly classic example of how things can go wrong.
The good news is that Google developers are now engaging with the community and trying to get their code into the mainline. This process could well be long, and require a fair amount of adjustment on the Android side. Even if the idea of wakelocks as a way to prevent the system from suspending is accepted - which is far from certain - the interface will require significant changes. The associated "early suspend" API - essentially a notification mechanism for system state changes - will need to be generalized beyond the specific needs of the G1 phone. It could well be a lot of work.
But if that work gets done, the kernel will be much better placed to handle the power-management needs of handheld devices. That, in turn, can only benefit anybody else working on embedded Linux deployments. And, crucially, it will help the Android developers as they port their code to other devices with differing needs. As the number of Android-based phones grows, the cost of carrying out-of-tree code to support each of them will also grow. It would be far better to generalize that support and get it into the mainline, where it can be maintained and improved by the community.
Most embedded systems vendors, it seems, would be unwilling to do that work; they are too busy trying to put together their next product. So this sort of code tends to languish out of the mainline, and the quality of embedded Linux suffers accordingly. Perhaps this case will be different, though; maybe Google will put the resources into getting its specialized code into shape and merged into the mainline. That effort could help to establish Android as a solid, well-supported platform for mobile use, and that should be good for business. Your editor, ever the optimist, hopes that things will work out this way; it would be a good demonstration of how embedded community can work better with the kernel community, getting a better kernel in return.
Many thanks firstly to the following:
ahalford: for his awesome thread and his awesome work and a great guy for allowing me to share his work here...please click the thanks for him for all this
chamonix and his team: for his awesome must have app BBS and for all the work they put in it...without that app we would be lost..
Entropy512: guy is a human wikipedia...
To all the kernel devs and those who explained in detail regarding the wakelocks definitions and everything else..
Like i said above i merely put all the info together from ahalford...he is the genius behind this thread and please click here to check his thread out and thank him...I will be adding my own info here as well and make this thread in the long term as my thread to be proud of..