Re: Attempted summary of suspend-blockers LKML thread

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Tue, Aug 03, 2010 at 10:22:55PM -0700, Arve Hjønnevåg wrote:
> On Tue, Aug 3, 2010 at 8:57 PM, Arjan van de Ven <arjan@infradead.org> wrote:
> > On Tue, 3 Aug 2010 17:10:15 -0700
> > "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> >>
> >> 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.
> >
> > for "system suspend", this is an absolutely valid statement.
> > for "use suspend as idle state", it's not so clearly valid.
> > (but this is sort of a separate problem, basically the "when do we
> > freeze the tasks that we don't like for power reasons" problem,
> > which in first order is independent on what kind of idle power state
> > you pick, and discussed extensively elsewhere in this thread)
> >
> >>
> >> 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 would argue that this is both a hardware specific issue, but also a
> > policy issue. From the user point of view, screen off with idle and
> > screen off with suspend aren't all that different (if my phone would
> > decide to idle rather than suspend because some app blocks suspend... I
> > wouldn't expect a difference in behavior when I touch the screen).
> > "Screen off -> don't honor touch after a bit" is almost an independent,
> > but very real, policy problem (and a forced one in suspend, I'll grant
> > you that). I could even argue that the policy decision "we don't care
> > about the touch screen input" is a pre-condition for entering suspend
> > (or in android speak, caring for touch screen input/having the touch
> > screen path active would be a suspend blocker)
> >
> >>
> >> 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.)
> >
> > I'll debate it even harder in that it's platform specific whether
> > timers can get the system out of suspend or not. Clearly on the Android
> > platform in question that's not the case, but for some of the Intel
> > phone silicon for example, timers CAN be wake sources to get you out of
> > suspend just fine. It just depend on which exact hw you talk about.
> > Generally, even if the fast timers aren't wake up sources, there'll be
> > some sort of alarm thing that you can pre-wake.. but yes you are right
> > in saying that's rather lame.
> > Either way, it's not a general property of suspend, but a property of
> > suspend on the specific platform in question.
> >
> 
> I disagree. On the msm platform the low level timer that brings us out
> of the low power state is the same for idle and suspend. The
> difference is where which kernel api the request comes from. In idle,
> the next event on the clockevents device is usually the first event.
> In suspend the generic kernel timekeeping code cancels this event and
> the rtc wakeup event remains.

OK, good point.  This choice of kernel APIs governs what I was calling
"policy".

							Thanx, Paul