Attempted summary of suspend-blockers LKML thread, take three
in [Kernel]
|
From: Paul E. McKenney on 10 Aug 2010 22:30 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. > >>>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! > >>>As to busting all apps, lthough there have been situations where busting > >>>all the apps turned out to be the right thing to do, I agree that these > >>>situations are extremely rare. Such situations are usually associated > >>>with the emergence of a new high-volume platform. > >> > >>Like Microsoft Windows 16bit co-operative multi-tasking ? It's rarely > >>right. It's merely that in certain cases the value in the market is large > >>enough that it can be used as a big stick to beat people into doing lots > >>of usually wasted work. > > > >Interesting choice of example. I do well remember the Sequent hardware > >guys' frustration when the old printer driver would monopolize the desktop > >while printing their large documents. The fact was that Microsoft's > >co-operative multi-tasking required all applications to be well behaved, > >just as does your approach to power efficiency. > > and wakelocks require all applications that can take a wakelock be > well behaved. and applications that do nt take a wakelock directly > cannot expect to run unless something else takes a wakelock on their > behalf Almost. Suspend blockers require that only those portions of a PM-driving application that hold a suspend blocker be carefully written to avoid wasting power. 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: david on 10 Aug 2010 23:10 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. 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/
From: Felipe Contreras on 11 Aug 2010 13:00 On Mon, Aug 9, 2010 at 12:38 AM, Ted Ts'o <tytso(a)mit.edu> wrote: > On Sun, Aug 08, 2010 at 08:40:28PM +0300, Felipe Contreras wrote: >> >> My guess is you haven't used a truly multi-tasking device like the >> N900; now that I've got used to it, I consider that functionality >> *essential*. > > I've used an N800, and I wasn't impressed; if anything, the fact that > I have to worry about manually killing off applications when memory > gets low, I actually thought it was incredibly sucky. It was a > miniature, badly done laptop. > > Maybe the N900 is different, but the bigger question is what do you > mean by "multi-tasking"? Definitions are critical here, which is why > Paul was so careful in his definitions section of his document. Yes, the N900 is drastically different, for starters, it has an actual window manager. 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. >> The argument in favor of suspend blockers is that you could take >> applications that are not designed for embedded, and make them run on >> an embedded device without draining excessive battery life; those >> applications would have to be background services not conflicting with >> Android's design. >> >> I agree there probably would not be that many background apps, and >> probably even less ported background apps, but that is actually an >> argument against suspend blockers. >> >> The rest of the apps (UI apps), cannot be ported, but have to be >> written specifically for Android, and therefore should have PM in >> mind, and not require suspend blockers to have good power usage. > > If you are using a GUI framework which is optimized for a single- > application-focus-at-a-time UI that isn't GNOME or KDE, then that will > require the applications to be written. However, that's not because > of suspend-blockers. Let's concentrate; Android is the only mobile platform that has expressed interested in suspend blockers. UI applications in Android are written specifically for Android. Period. Other platforms, such as MeeGo, rely on Qt API, not suspend blockers. > If you assume a GUI framework which is flexible enough --- maybe Qt > falls into this category, maybe not --- for the rest of the > applications, they don't need to *know* about suspend blockers, and > they certainly do't have to be rewritten or modified specifically for > suspend blockers. So if your argument is that applications that don't > need bacground services (which you've admitted comprises majority of > applicatios) need to be modified or written specifically to support > suspend blockers, that's simply not true. They don't need to be > modified at all. That's not my argument at all. I was talking about a counter-argument to "suspend blockers make porting desktop apps easer". Android's UI applications are unimportant here because they have not been ported from the desktop realm; they were designed specifically for Android, including all its PM capabilities. The only relevant applications are the ones designed for the desktop that are ported to Android, and thus might make assumptions that hurt battery life. These are background services. If you are saying that there are few background apps, then that's an argument against suspend blockers: 1) few applications can be ported 2) the few applications that can be ported, being background services, might miss timers and behave worst than _without_ suspend blockers > As far as whether they *should* require suspend blockers to be in the > kernel to get power usage that is suitable for cell phone batteries, I > would agree that in the ideal world, it would be nice if you could > have applications that make the correct performance/battery > utilization tradeoff for devices running on 800 mWh batteries, 94,000 > mWh batteries, and while running on the AC mains. But I don't believe > that it's likely to be true, and if you want to try to beat up on > application writers one at a time to be power optimized --- as far as > I'm concerned, that's an argument *for* suspend blockers, since I'm > not big believer in plans that begin, "First, you command the tides of > the sea to go back", King Canute style. :-) Power is just like any other resource, why are desktop applications not using 100% CPU, or 100% of memory? Because if they did nobody would be using them. There's a social pressure to use less resources, or at least less resources than the competence. If an application uses too much battery time nobody would use it, unless perhaps if the functionality is too good and there are no alternatives. I believe social forces already deal with this problem, all we need to do is provide better tools, not patronize user-space applications. -- 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: Felipe Contreras on 11 Aug 2010 15:20 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? -- 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: Felipe Contreras on 11 Aug 2010 15:30
On Tue, Aug 10, 2010 at 7:45 AM, Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> wrote: > On Mon, Aug 09, 2010 at 08:18:22PM +0100, Alan Cox wrote: >> You are tightly linking suspend blockers with Android. If they were a >> sensible general solution they would be generic not tied closely to >> Android > > Android is certainly where suspend blockers originated, and is to the best > of my knowledge is still the only platform that uses them. But there is > a first user of every new mechanism, and for some time that first user > will by definition be the only user of that mechanism. So the fact > that Android is most probably the only user of suspend blockers does > not prove anything about whether or not suspend blockers are sensible. No, it's the fact that *nobody* else has said: hey, that looks like a good idea, we should use that in our mobile platform (or any platform). -- 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/ |