Date:	Wed, 4 Aug 2010 22:46:33 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	paulmck@...ux.vnet.ibm.com
Cc:	Arjan van de Ven <arjan@...radead.org>, david@...g.hm,
	Arve Hjønnevåg <arve@...roid.com>,
	"Ted Ts'o" <tytso@....edu>, linux-pm@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, mjg59@...f.ucam.org, pavel@....cz,
	florian@...kler.org, stern@...land.harvard.edu,
	swetland@...gle.com, peterz@...radead.org, tglx@...utronix.de,
	alan@...rguk.ukuu.org.uk
Subject: Re: Attempted summary of suspend-blockers LKML thread

On Wednesday, August 04, 2010, Paul E. McKenney wrote:
> On Tue, Aug 03, 2010 at 08:57:58PM -0700, Arjan van de Ven wrote:
> > On Tue, 3 Aug 2010 17:10:15 -0700
> > "Paul E. McKenney" <paulmck@...ux.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)
> 
> From what I can see, the Android folks are are using "suspend" in
> the "system suspend" sense.
> 
> I agree that the proposals for freezing subsets of the tasks in the
> system are independent of whether idle or suspend is being used.
> Instead, such freezing depends on (for example) whether or not the
> display is active.
> 
> That said, freezing subsets of tasks is a nice-to-have rather than a
> hard requirement for Android.  Though I suspect that the appearance
> of a reliable way of freezing subsets of tasks just might promote
> this to a hard requirement.  ;-)
> 
> > > 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)
> 
> I agree that the subset of input events that do not bring the system out
> of suspend would be governed both by hardware capabilities and by policy.
> 
> > > 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.
> 
> Good point, I do need to emphasize the fact that whether or not timers
> pull the system out of suspend also depends both on hardware and
> on policy.  So I will change my statement to say something like "The
> system comes out of a deep idle state when a timer expires.  In contrast,
> timers do not necessarily expire while the system is suspended, depending
> on both hardware support and platform/application policy."

That's correct IMO.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists