On Thu, Aug 5, 2010 at 3:31 PM, Paul E. McKenney
On Thu, Aug 05, 2010 at 01:13:31PM -0500, kevin granade wrote:On Thu, Aug 5, 2010 at 10:46 AM, <david@xxxxxxx> 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
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
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.