Re: Attempted summary of suspend-blockers LKML thread, take three

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

On Tue, Aug 10, 2010 at 08:00:53PM -0700, david@lang.hm wrote:
> On Tue, 10 Aug 2010, Paul E. McKenney wrote:
> 
> >Subject: Re: Attempted summary of suspend-blockers LKML thread, take three
> >
> >On Tue, Aug 10, 2010 at 06:28:39PM -0700, david@lang.hm wrote:
> >>On Tue, 10 Aug 2010, Paul E. McKenney wrote:
> >>
> >>>On Tue, Aug 10, 2010 at 09:38:49AM +0100, Alan Cox wrote:
> >>>>>situation you call out can occur with manual suspend-to-RAM already:
> >>>>>the fact is that this is a design choice.  You could indeed make a
> >>>>
> >>>>Losing data is a design choice ? The application set a timer, the OS
> >>>>shouldn't be ignoring it in that situation. It might want to delay it, it
> >>>>might want to warn the user its hogging things it shouldnt (powertop,
> >>>>battery usage monitors in Android etc)
> >>>
> >>>Hmmm...  Let's put the two approaches side by side so that we can compare
> >>>them more easily:
> >>>
> >>>	Opportunistic Suspend		Idle + Timer Jitter
> >>>
> >>>	Set timer			Set timer
> >>>	Suspend				OS delays timer
> >>>	Resume				OS continues delaying timer
> >>>	Timer fires			Timer fires
> >>>
> >>>These two cases look quite similar to me.
> >>>
> >>>But as you say, the battery can run out.  So let's add that to the
> >>>comparison:
> >>>
> >>>	Opportunistic Suspend		Idle + Timer Jitter
> >>>
> >>>	Set timer			Set timer
> >>>	Suspend				OS delays timer
> >>>	Battery runs out		Battery runs out
> >>>	Data loss			Data loss
> >>>
> >>>The two cases still look quite similar.  You might note, quite correctly,
> >>>that the time between suspend and resume might be quite a bit longer than
> >>>the typical time that the OS delays a timer.  But the power consumption
> >>>on some platforms is quite a bit lower in the suspend case than it is
> >>>in the delayed-timer case.
> >>
> >>it has been stated that the android can hit the exact same power
> >>state either with sleep or suspend, and that the same clock can wake
> >>it up (it appears as a timer expiring for sleep, or an alarm for
> >>suspend, but it's the same clock firing the signal)
> >>
> >>so in at least some cases the hardware supports doing both with
> >>equal efficiency.
> >
> >It indeed has been so stated.  But in this section we were discussing
> >data loss, not hardware power-state capabilities.
> 
> you specifically stated that suspend would use less power. I am
> pointing out that ther is info posed in this thread to say that's
> not always the case.

I specifically stated something different, and if you specifically look
up a few paragraph, you will specifically see that I specifically used
a specific qualifier, which you specifically seem to have lost track of.

							;-), Paul

> in either case it is possible for the system to wake up again later
> to let the timer fire and the application save it's work. It's
> arguably easier in the idle case as it doesn't require application
> modification
> 
> for example
> 
> Idle + Timer Jitter
> set timer
> OS sets timer jitter to 1 hour
> system sleeps for 1 hour with no wakeups
> timer fires, applications wake and process data
> system sleeps (for 1 hour or more with no wakeups)
>  (repeat as needed until battery runs out)
> 
> much less chance for data loss as there is _far_ more of a chance
> that the timer
> 
> waking up once per hour for a short time is not going to make a
> noticable difference in your total battery life of a cell phone due
> to the significant idle power draw needed for the cell circuitry. On
> something like a e-reader with no radio link and a month-long idle
> time it could make a difference.
> 
> note that this is with a badly written app running that is trying to
> wakeup repeatedly. If the app is well behaved and only schedule a
> timer when they will have work to do, they may not schedule a timer
> at all after the data is saved, and so would have the data safe and
> just as long a standby time.
> 
> >>>>>But that doesn't guarantee that solutions developed for PCs and laptops
> >>>>>will be optimal (or even usable) on cellphones.  Sufficient difference
> >>>>
> >>>>Your cellphone is to all intents a laptop from ten years ago, it even has
> >>>>a similar display resolution and internet availability. The underlying
> >>>>difference between the two is solely form factor - the laptop had a
> >>>>better keyboard.
> >>>
> >>>There are similarities and differences.  You have called out some of
> >>>the similarities.  Differences include the more-aggressive hardware
> >>>power management on cellphones, the greater number and variety of
> >>>hardware accelerators on cellphones, battery capacity, and, as you say,
> >>>physical size.  People currently use cellphones differently than they
> >>>do laptops or desktops.  The usage might converge, but we will see.
> >>>There is as much reason to expect increasing specialization as there
> >>>is to expect increasing convergence.
> >>
> >>You are talking about Android as if it was a cell phone only thing,
> >>it's not. there are shipping tablets (and I believe netbooks, i.e.
> >>laptops) running andoid.
> >
> >I was talking about cellphones.  But yes, Android (and thus suspend
> >blockers) are used for tablets as well as cellphones, thank you for
> >reminding me!
> 
> the fact that it's used there means that you can't argue that it's
> difference because cell phones are so different (unless you are
> saying that Android is really not appropriate for those uses)
> 
> On the other hand, lots of things are used in places where it is
> inappropriate, Windows CE is used on phones, tablets, etc but I
> think most people would say that the use of windows there isn't
> appropriate.
> 
> David Lang