Wakelocks and the embedded problem

Posted Dec 31, 2011 11:55 UTC (Sat) by ErikEngerd (guest, #82043)
In reply to: Wakelocks and the embedded problem by jd
Parent article: Wakelocks and the embedded problem

It is now almost 2012 and I still regularly find myself tracing wake lock issues on a recent Android phone. I think that whatever the solution to this problem is, the kernel should be in control over wake locks. In particular, when a process exits, all its wake locks should be released.

In addition, I am wondering why wake locks are even needed. Shouldn't the cpu go to a low power state whenever possible automatically? What exactly is the problem that a wake lock is intended to solve? Is it just scheduling of background tasks?

Perhaps it would also be good to have something like policies in linux defining how often/when certain processes may run (perhaps an extension to selinux?).

Anyway, I think the current implementation with putting the responsibility for wake locks in user space is really fragile. Many users are experiencing poor battery life because of this and are not technical enough to find the cause. Having a solution where the kernel is in control would be a big step in the right direction, I think.

Wakelocks and the embedded problem

Posted Dec 31, 2011 19:30 UTC (Sat) by dlang (guest, #313) [Link] (1 responses)

this is the heart of the disagreement over wakelocks being _the_ solution to the power problem.

there are problems with switching the system into low power mode

1. some things don't work in some low power modes

2. it takes time to switch out of low power modes

linux systems have been switching to low power modes automatically for quite a few years, but they only switch to modes that are going to be transparent to the user (unless they are watching for it).

In addition to these power saving modes, there are the 'suspend' and 'hibernate' modes where they system stops all processing. Traditional systems try to determine that the system is idle for a long enough time period before going into suspend.

the idea behind the userspace wakelocks can be paraphrased into having an extremely short (approaching zero) timer for going into suspend, but only if nothing is holding a wakelock to keep the system awake.

In my opinion, this idea is mostly defeated by the fact that they don't trust regular programs to take the wakelock, and instead have a central power management daemon that does things like hold the wakelock the entire time the screen is lit.

now, something similar to the wakelock was needed in the kernel to keep the system from going to sleep at the same time that a new event was happening that would cause the system to wake up (to prevent a race condition), and a mechanism to do this was added to the kernel a year or so ago (but is not yet used by Android)

Wakelocks and the embedded problem

Posted Mar 26, 2012 17:07 UTC (Mon) by bgat (guest, #20709) [Link]

I think that runtime-pm is very, very close to being a complete replacement for wakelocks. At least for platforms with drivers that fully support it.

The nice thing about runtime-pm is that it is fully aware of the kernel's Device Model, and can therefore make better decisions about system state than wakelocks can. The downside is that it looks nothing like existing wakelocks, so it requires movement from Android.