On Wed, Aug 04, 2010 at 03:29:25PM -0700, david@xxxxxxx wrote:On Wed, 4 Aug 2010, Paul E. McKenney wrote:On Wed, Aug 04, 2010 at 12:29:36PM -0700, david@xxxxxxx wrote:On Wed, 4 Aug 2010, Matthew Garrett wrote:
There's two parts of that. The first is that the voip application is
allowed to take a wakelock - but that doesn't mean that you trust it the
rest of the time.
why would you trust it to take a wakelock, but not trust it the rest
of the time?
in my proposal I'm saying that if you would trust the application to
take a wakelock, you instead trust it to be sane in the rest of it's
power activity (avoiding polling, etc) and so you consider it for
sleep decisions.
The word "trust" does not appear to be helping here. ;-)
The VOIP application acquires a suspend blocker when it needs to prevent
the system from suspending, and releases that suspend blocker when it
can tolerate the system suspending. It is important to note that while
the VOIP application holds the suspend blocker, the system won't suspend
even if it is completely idle (for example, if the VOIP application uses
blocking system calls, during the time that the VOIP application is
waiting for its next event).
In the terminology I have been using, the VOIP sofware is then
trusted to take the wakelock appropriately, and I'm then saying it
would be in the trusted cgroup
Understood, but...
it would be trusted to not use the CPU wildly inappropriatly and so
it running would make the system active and so it would not sleep.
... here you seem to be assuming that "trusted to properly use a wakelock"
implies "coded to optimize power usage when not holding a wakelock."
But this does not necessarily follow.
2. The application is prohibited from acquiring suspend blockers.
In this case, the system might well be suspended before the
application has a chance to do more than read the input.
But the application will get a chance to process the input
when the next input event is directed to it.
In this case the system would go ahead and suspend, but the next
time the sustem wakes up for any reason, this application would
continue to run and process the input
Yep, that is in fact what I said. ;-)
two things here,
on the dirty networks that I see as common, refusing to sleep if
network packets are arriving will mean that you never go to sleep.
secondly, nothing stops the code doing the idle/suspend decision
from considering network activity. I would be surprised if there
weren't already options to support this today.
I don't know about the general networking case for Android, but the
example of downloading was discussed some time back. The application
doing the download acquires a suspend blocker, which it releases once
the download is complete (or once a timeout expires, if I remember
correctly). In this particular case, the network packets were not
bringing the device out of suspend.
it would seem reasonable to say that if a packet arrives for an
existing connection (which the kernel does know) it is considered
activity for purposes of sleeping.
That would be up to the people creating the system in question. In
some cases, they might (as you say) want every packet arriving to
wake up the system, in other cases they might not. We should not
be taking that design decision away from them.
I don't know if you would care enough to try and say that packets
for untrusted apps network connections don't keep the system awake,
or just allow them to (after all, keypresses going to untrusted apps
do keep the system awake)
Again, this is up to the people creating the system in question. On
some Android systems, there is a particular button you have to press
to wake the system up after it has suspended itself.
There might well be other cases where networking packets -do- bring
the system out of suspend, but I must leave this to someone who knows
more about Android than do I.
this would be the normal wake-on-lan type of functionality that
exists without Android.
Although this wake-on-LAN functionality applies only to special
wake-up packets, not to normal packets, right?