> On Tue, Aug 03, 2010 at 08:39:22PM -0700, Arve Hjønnevåg wrote:
> > On Tue, Aug 3, 2010 at 5:51 PM, <david@lang.hm> wrote:
> > > On Tue, 3 Aug 2010, Paul E. McKenney wrote:
> > >
> > >> On Tue, Aug 03, 2010 at 04:19:25PM -0700,
david@lang.hm wrote:
> > >>>
> > >>> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
> > >>>
> > >>>> 2010/8/2 <david@lang.hm>:
> > >>>>>
> > >>>>> 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...
> > >
> > > thanks, this is not intended to be a trap.
> > >
> > >> 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.
> > >
> > > Ok, this is a complication to what I'm proposing (and seems a little odd,
> > > but I can see how it can work), but not neccessarily a major problem. it
> > > depends on exactly how the decision is made to go into low power states
> > > and/or suspend. If this is done by an application that is able to look at
> > > either all activity or ignore one cgroup of processes at different times in
> > > it's calculations than this would work.
> > >
> > >> 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.
> > >
> > > I see this as simply being a matter of what devices are still enabled at the
> > > different power savings levels. At one level the touchscreen is still
> > > powered, while at another level it isn't, and at yet another level you have
> > > to hit the power soft-button. This isn't fundamentally different from
> > > powering off a USB peripheral that the system decides is idle (and then not
> > > seeing input from it until something else wakes the system)
> >
> > The touchscreen on android devices is powered down long before we
> > suspend, so that is not a good example. There is still a significant
> > difference between suspend and idle though. In idle all interrupts
> > work, in suspend only interrupts that the driver has called
> > enable_irq_wake on will work (on platforms that support it).
> >
> > >> 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.)
> > >
> > > if you have the ability to wake for an alarm, you have the ability to wake
> > > for a timer (if from no other method than to set the alarm to when the timer
> > > tick would go off)
> >
> > If you just program the alarm you will wake up see that the monotonic
> > clock has not advanced and set the alarm another n seconds into the
> > future. Or are proposing that suspend should be changed to keep the
> > monotonic clock running? If you are, why? We can enter the same
> > hardware states from idle, and modifying suspend to wake up more often
> > would increase the average power consumption in suspend, not improve
> > it for idle. In other words, if suspend wakes up as often as idle, why
> > use suspend?
>
> Hmmm... The bit about the monotonic clock not advancing could help
> explain at least some of the heartburn from the scheduler and real-time
> folks. ;-)
