Re: Attempted summary of suspend-blockers LKML thread

From: david
Date: Wed Aug 04 2010 - 18:30:49 EST

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:

On Wed, Aug 04, 2010 at 12:15:59PM -0700, david@xxxxxxx wrote:
On Wed, 4 Aug 2010, Matthew Garrett wrote:
No! And that's precisely the issue. Android's existing behaviour could
be entirely implemented in the form of binary that manually triggers
suspend when (a) the screen is off and (b) no userspace applications
have indicated that the system shouldn't sleep, except for the wakeup
event race. Imagine the following:

1) The policy timeout is about to expire. No applications are holding
wakelocks. The system will suspend providing nothing takes a wakelock.
2) A network packet arrives indicating an incoming SIP call
3) The VOIP application takes a wakelock and prevents the phone from
suspending while the call is in progress

What stops the system going to sleep between (2) and (3)? cgroups don't,
because the voip app is an otherwise untrusted application that you've
just told the scheduler to ignore.

Even in the current implementation (wakelocks), Since the VOIP
application isn't allowed to take a wakelock, wouldn't the system go to
sleep immediatly anyway, even if the application gets the packet and
starts the call? What would ever raise the wakelock to keep the phone
from sleeping in the middle of the call?

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

The second is that the incoming network packet causes
the kernel to take a wakelock that will be released once userspace has
processed the network packet. This ensures that at least one wakelock is
held for the entire relevant period of time.

how do you determine that userspace has processed the network packet
so that the kernel can release the wakelock (or is this one of the
cases where there is a timer related to the wakelock)

There are two cases:

1. The application is permitted to acquire suspend blockers.
In this case, the application would acquire a suspend blocker
before reading the input. It would then read the input (at
which point the kernel releases its suspend blocker), do any
needed processing, and finally release the suspend blocker.

So in this case, the system knows that the application is
done processing the input when that application releases
its suspend blocker.

in my proposal, the application is trusted to take the wakelock, so 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.

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

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.

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)

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.

The primary thing that I was getting at was the other things above.

David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/