On Thu, 5 Aug 2010 07:33:59 +0200
Florian Mickler <florian@xxxxxxxxxxx> wrote:
On Wed, 4 Aug 2010 16:10:03 -0700
"Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> wrote:
No no. In the David-Lang-CGroup-Scheme(tm?) suspend-from-idle
is used. For idle decision a certain subset of tasks is ignored.
Where suspend is prevented by the trusted
process in android-world taking a wakelock, here it would just prevent
the system from going idle by arming timers.
This would be pretty equivalent to the suspend-blocker scheme and not
introduce new userspace api. But the downside is, as Arve pointed out,
that now one can not get full-idle-power-leverage while suspend
 http://permalink.gmane.org/gmane.linux.kernel/1018452 and
There are a few downsides that got mentioned already in reponse.. I got
a little lagged behind.
There are upsides to this approach like not
having a special purpose userspace api, conceptually integrating
suspend into the idle mechanism ..
Short summary of the cons that got mentioned:
- applications need to resort to polling to keep the system
out of idle (-> system will never be fully idle)
- the race between deciding to suspend and becoming active
again is not handled
- no special statistics available
- the timers of the ignored applications will behave unexpected
(as the monotonic clock is not stopped)... while applications
have already to cope with network-loss, other side effects of
suspend without monotonic clock stopped are to be expected...