Attempted summary of suspend-blockers LKML thread, take three
in [Kernel]
|
From: Felipe Contreras on 11 Aug 2010 18:10 On Thu, Aug 12, 2010 at 12:37 AM, Brian Swetland <swetland(a)google.com> wrote: > On Wed, Aug 11, 2010 at 2:25 PM, Felipe Contreras > <felipe.contreras(a)gmail.com> wrote: >> Now, only Android has decided to use suspend blockers, that's a >> *fact*, and I wanted to narrow the discussion to Android in order to >> make it easier to understand that Android doesn't need suspend >> blockers, once we have agreed that, then I'd gladly discuss it's >> merits outside Android. > > On behalf of the Android folks, we don't agree with this. If you're > going to wait until we suddenly change our minds, I think you're going > to be in for a long wait. I'm sure as a team that's the case, but you can't know what's in the mind of everyone at Google (not Android). >> I argued to you that suspend-blockers are not required in Android, and >> suddenly you decide we should agree to disagree without arguing back? >> Well, suit yourself. I still maintain that suspend-blockers is just an >> expensive workaround, and in some cases actually degrades power >> consumption; the right solution is much more sophisticated. > > Once "the right solution" exists and solves our problems, we'll > certainly look into switching over to it. I've yet to see a proposal > in all this arguing that appears to me to be an improvement over what > we have today with suspend blockers. I find the "don't do what you're > doing because someday, somebody will do it better" to be an > uncompelling argument. That was not an argument, it was an opinion. If you want an argument go back to read this one: http://article.gmane.org/gmane.linux.kernel/1021834 > Given your opinion that Android lacks multitasking (what? really?) This is what I'm talking about when I say multi-tasking, Android certainly doesn't have anything remotely like that: http://www.youtube.com/watch?v=7emvUBpEkbU -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Paul E. McKenney on 11 Aug 2010 18:20 On Wed, Aug 11, 2010 at 11:00:42PM +0300, Felipe Contreras wrote: > On Wed, Aug 11, 2010 at 3:42 AM, Paul E. McKenney > <paulmck(a)linux.vnet.ibm.com> wrote: > > On Tue, Aug 10, 2010 at 09:38:49AM +0100, Alan Cox wrote: > >> You may also wish to review the earlier parts of the discussion where it > >> was explicitly stated by several developers that they were using > >> "suspend" type modes as power states already and not using suspend > >> blockers. So it's being done, today on ARM and your statement is directly > >> contradicting the code. Modern ARM processors and x86 MID devices can > >> suspend and resume extremely fast (fast enough that the fact Linux x86 > >> rewriting all the SMP alternatives on suspend/resume is a measurable > >> problem). If this same property doesn't end up on big PC boxes in time > >> then I'd be very surprised. At that point the openoffice with suspend > >> blockers or oracle with suspend blockers question becomes rather relevant. > > > > Here is the list of properties distinguishing idle from suspend: > > > > 1. � � �Idle states are entered by a given CPU only there are no runnable > > � � � �tasks for that CPU. �In contrast, opportunistic suspend can > > � � � �halt the entire system even when there are tasks that are ready, > > � � � �willing, and able to run. �(But please note that this might not > > � � � �apply to real-time tasks.) > > But if there are no runnable tasks (which is the target), they behave the same. And if there are runnable tasks, then then don't behave the same. Apparently different people in this debate have different targets. > > 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 idle. > > � � � �Exactly which events are in this set depends both on hardware > > � � � �capabilities and on the platform/application policy. �For example, > > � � � �on one of the Android-based smartphones, touchscreen input is > > � � � �ignored when the system is suspended, but is handled when idle. > > And in N900 touching the screen doesn't bring the device out of idle, > I guess because it's off. As long as touching the N900 screen doesn't bring the device out of suspend, its behavior is not a counterexample to #2 above. > What devices do what on which circumstances on what platform is > completely irrelevant. Do you -really- want me to start listing counterexamples to that brave statement? ;-) > > 3. � � �The system comes out of idle when a timer expires. �In contrast, > > � � � �timers might or might not bring the system out of suspend, > > � � � �depending on both hardware capabilities and platform/application > > � � � �policy. > > Isn't this solved by range timers? Ahem. This is a list of differences between idle and suspend, not a list of problems to be solved. But to answer your question, if a timer does not bring a given device out of suspend, then a range timer is not likely to, either. Don't get me wrong, I do believe that range timers have an important part to play in the energy-efficiency arena, but I have not been convinced that they are any kind of silver bullet. > > 4. � � �Suspend generally forces devices to go into their low-power > > � � � �states immediately. �In contrast, idle generally leaves unused > > � � � �devices at full power, relying on timers to shut down these > > � � � �devices. �Idle thus has shorter average wakeup latencies, but > > � � � �worse energy efficiency. > > Only if you make these assumptions > 1) All the applications use suspend-blockers only when they absolutely must > 2) The user has given the right applications the right access You believe that these assumptions are unreasonable? Compared to the assumption that all applications are carefully written to conserve power? If so, on what grounds? It seems to me that the same social-engineering approaches work in both cases. > If not, you'll see much worst energy efficiency. So in theory maybe, > but in practice you can't say that. Really? What makes you say that? Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Brian Swetland on 11 Aug 2010 18:20 On Wed, Aug 11, 2010 at 3:03 PM, Felipe Contreras <felipe.contreras(a)gmail.com> wrote: >> Once "the right solution" exists and solves our problems, we'll >> certainly look into switching over to it. I've yet to see a proposal >> in all this arguing that appears to me to be an improvement over what >> we have today with suspend blockers. I find the "don't do what you're >> doing because someday, somebody will do it better" to be an >> uncompelling argument. > > That was not an argument, it was an opinion. If you want an argument > go back to read this one: > http://article.gmane.org/gmane.linux.kernel/1021834 > >> Given your opinion that Android lacks multitasking (what? really?) > > This is what I'm talking about when I say multi-tasking, Android > certainly doesn't have anything remotely like that: > http://www.youtube.com/watch?v=7emvUBpEkbU Home + pick app -> switch to the app in whatever state it was in. Home (longpress) -> recent app list + pick app from popup -> switch to recent app in whatever state it was in. pull down alert windowshade + pick app from alerts list -> switch to that app I routinely flip back and forth between email / browser / IM / musicplayer / etc I have no problem with you perhaps liking the visuals of the N900 better, but to say Android lacks multitasking (as you explain it below) is incorrect: > By multi-tasking I mean me (the user) being able to perform multiple > tasks at the same time. > For example: writing an email, while browsing the web, while having IM > conversations. Obviously not exactly at the same time; start writing > an email, go browse for some url, copy, answer a pending IM message, > go back to the mail, paste. As far as implementing app switching with a deck of cards metaphor, I've seen that done by some OEMs with Android, though it's not the default system UI. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Paul E. McKenney on 11 Aug 2010 18:30 On Wed, Aug 11, 2010 at 10:18:51PM +0300, Felipe Contreras wrote: > On Mon, Aug 9, 2010 at 9:16 PM, Paul E. McKenney > <paulmck(a)linux.vnet.ibm.com> wrote: > > But wouldn't an office suite run as a power-oblivious application on an > > Android device? �After all, office applications do not need to run when > > the screen is turned off, so these the applications do not need to use > > suspend blockers. > > Ideally the system would be suspended even when the screen is on. If > there are no "trusted" applications running at the same time, then > openoffice wouldn't load at all. Right? My understanding is that Android systems in fact do not suspend when the screen is on, and that most (perhaps all) other systems do not opportunistically suspend at all. There has been some speculation about what a hypothetical Android having a non-volatile display might do, but as far as I know, this is just speculation. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Paul E. McKenney on 11 Aug 2010 19:00
On Tue, Aug 10, 2010 at 08:00:53PM -0700, david(a)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(a)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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |