Messages in this thread | | | Date | Thu, 5 Aug 2010 15:09:32 -0700 (PDT) | From | david@lang ... | Subject | Re: Attempted summary of suspend-blockers LKML thread |
| |
On Thu, 5 Aug 2010, kevin granade wrote:
> On Thu, Aug 5, 2010 at 3:31 PM, Paul E. McKenney > <paulmck@linux.vnet.ibm.com> wrote: >> On Thu, Aug 05, 2010 at 01:13:31PM -0500, kevin granade wrote: >>> On Thu, Aug 5, 2010 at 10:46 AM, <david@lang.hm> wrote: >>>> On Thu, 5 Aug 2010, Paul E. McKenney wrote: >>>> >>>>> >>>>> [ . . . ] >>>>> >>>>> >>>>> My (possibly incorrect) assumption is based on the complaint that led >>>>> to my implementing RCU_FAST_NO_HZ. A (non-Android) embedded person was >>>>> quite annoyed (to put it mildly) at the earlier version of RCU because >>>>> it prevented the system from entering the power-saving dyntick-idle mode, >>>>> not for minutes, or even for seconds, but for a handful of -milliseconds-. >>>>> This was my first hint that "energy efficiency" means something completely >>>>> different in embedded systems than it does in the servers that I am >>>>> used to. >>>>> >>>>> But I must defer to the Android guys on this -- who knows, perhaps >>>>> multi-minute delays to enter full-suspend mode are OK for them. >>>> >>>> if the system was looking at all applications I would agree that the timeout >>>> should be much shorter. >>>> >>>> I have a couple devices that are able to have the display usable, even if >>>> the CPU is asleep (the OLPC and the Kindle, two different display >>>> technologies). With these devices I would like to see the suspend happen so >>>> fast that it can suspend between keystrokes. >>>> >>>> however, in the case of Android I think the timeouts have to end up being >>>> _much_ longer. Otherwise you have the problem of loading an untrusted book >>>> reader app on the device and the device suspends while you are reading the >>>> page. >>>> >>>> currently Android works around this by having a wakelock held whenever the >>>> display is on. This seems backwards to me, the display should be on because >>>> the system is not suspended, not the system is prevented from suspending >>>> because the display is on. >>>> >>>> Rather than having the display be on causing a wavelock to be held (with the >>>> code that is controls the display having a timeout for how long it leaves >>>> the display on), I would invert this and have the timeout be based on system >>>> activity, and when it decides the system is not active, turn off the display >>>> (along with other things as it suspends) >>> >>> IIRC, this was a major point of their (Android's) power management >>> policy. User input of any kind would reset the "display active" >>> timeout, which is the primary thing keeping random untrusted >>> user-facing programs from being suspended while in use. They seemed >>> to consider this to be a special case in their policy, but from the >>> kernel's point of view it is just another suspend blocker being held. >>> >>> I'm not sure this is the best use case to look at though, because >>> since it is user-facing, the timeout durations are on a different >>> scale than the ones they are really worried about. I think another >>> category of use case that they are worried about is: >>> >>> (in suspend) -> wakeup due to network -> process network activity -> suspend >>> >>> or an example that has been mentioned previously: >>> >>> (in suspend) -> wakeup due to alarm for audio processing -> process >>> batch of audio -> suspend >>> >>> In both of these cases, the display may never power on (phone might >>> beep to indicate txt message or email, audio just keeps playing), so >>> the magnitude of the "timeout" for suspending again should be very >>> small. Specifically, they don't want there to be a timeout at all, so >>> as little time as possible time is spent out of suspend in addition to >>> the time required to handle the event that caused wakeup. >> >> It would be good to get some sort of range for the "timeout". In the >> audio-output case, my understanding that the spacing between bursts of >> audio-processing activity is measured in some hundreds of milliseconds, >> in which case one would want the delays until suspend to be on the >> millisecond scale. But does Android really suspend between bursts of >> audio processing while playing music? Very cool if so! ;-) > > Oops, yea that's actually a really bad example, that's probably > something that would be handled by low-power states. I think the > incoming text message example is a good one though. There seemed to > be a focus on user-interaction scale time scales, and I wanted to > point out that there are also very short duration time scales to > consider as well.
good point, but I do think the short time scales are less common than people think.
I'd love to get good examples of them
on my iphone when a text message arrives the phone displays an alert for user-interaction times (it even lights the display to show who the message is from, and optionally a preview of the message)
so what would wake a phone up from suspend where the phone should go back to sleep in under a second?
David Lang | |