On Tue, Aug 10, 2010 at 08:00:53PM -0700, david@xxxxxxx 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@xxxxxxx 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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
