On Tue, Aug 03, 2010 at 04:19:25PM -0700, david@xxxxxxx wrote:On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
2010/8/2 <david@xxxxxxx>:
so what is the fundamental difference between deciding to go into low-power
idle modes to wake up back up on a given point in the future and deciding
that you are going to be idle for so long that you may as well suspend until
there is user input?
Low power idle modes are supposed to be transparent. Suspend stops the
monotonic clock, ignores ready threads and switches over to a separate
set of wakeup events/interrupts. We don't suspend until there is user
input, we suspend until there is a wakeup event (user-input, incoming
network data/phone-calls, alarms etc..).
s/user input/wakeup event/ and my question still stands.
low power modes are not transparent to the user in all cases (if the
screen backlight dimms/shuts off a user reading something will
notice, if the system switches to a lower clock speed it can impact
user response time, etc) The system is making it's best guess as to
how to best srve the user by sacraficing some capibilities to save
power now so that the power can be available later.
as I see it, suspending until a wakeup event (button press, incoming
call, alarm, etc) is just another datapoint along the same path.
If the system could not wake itself up to respond to user input,
phone call, alarm, etc and needed the power button pressed to wake
up (or shut down to the point where the battery could be removed and
reinstalled a long time later), I would see things moving into a
different category, but as long as the system has the ability to
wake itself up later (and is still consuming power) I see the
suspend as being in the same category as the other low-power modes
(it's just more expensive to go in and out of)
why should the suspend be put into a different category from the
other low-power states?
OK, I'll bite...
From an Android perspective, the differences are as follows:
1. Deep idle states are entered only if there are no runnable tasks.
In contrast, opportunistic suspend can happen even when there
are tasks that are ready, willing, and able to run.
2. There can be a set of input events that do not bring the system
out of suspend, but which would bring the system out of a deep
idle state. For example, I believe that it was stated that one
of the Android-based smartphones ignores touchscreen input while
suspended, but pays attention to it while in deep idle states.
3. The system comes out of a deep idle state when a timer
expires. In contrast, timers cannot expire while the
system is suspended. (This one is debatable: some people
argue that timers are subject to jitter, and the suspend
case for timers is the same as that for deep idle states,
but with unbounded timer jitter. Others disagree. The
resulting discussions have produced much heat, but little
light. Such is life.)
There may well be others.
Whether these distinctions are a good thing or a bad thing is one of
the topics of this discussion. But the distinctions themselves are
certainly very real, from what I can see.
Or am I missing your point?