Attempted summary of suspend-blockers LKML thread, take three
in [Kernel]
|
From: Ted Ts'o on 8 Aug 2010 12:00 On Sun, Aug 08, 2010 at 03:53:52PM +0300, Felipe Contreras wrote: > > You are overgeneralizing; there are many applications that run in the > background, and you want to keep them running even when the display is > off. Really? How many do you really expect will be running at the same time on a mobile platform with a 800-1000 mWh battery? And what percentage of the applications that might be in a Android or Moblin or Maemo app store will have things running in the background? 10%? 20%? 50%? 80%? > You seen to be concentrating on UI-only applications, for those it's > worth noting that Android provides separate mechanisms for power > saving. Since Android doesn't have true multi-tasking, the > applications must serialize their states so that the next time they > are opened they seem to have not been closed. So, the current active > UI application can be closed while turning off the display, and > re-opened later. Actually in practice, the process or processes which comprise current active UI application generally won't actually be killed when you turn off the display. It *might* happen, if one of the rare backround applications needs more memory than is available without closing some of the more recently open applications. In practice, the last 2-3 most recently used applications are still loaded in memory so you can switch back and forth between them simply and easily. It is true they have to be ready to be killed at any time in case their memory is needed for the currently active application, but that generally does't happen right away. The design is to keep this transparent to the user so the user does't have to keep track of how many apps currently running on the system. In any case, the key thing to keep in mind is that when you deal with extreme power savings, very often you end up making compromises that probably make sense for other reasons anyway (such as the small screen size). It's not at all clear that supporting generalized multi-tasking applications makes sense just from a screen real-estate issue and user experience POV, never mind battery lifetime. > User-space suspend blockers are relevant for background services, and > as it has been discussed before; suspend blockers (not activating > them) might actually degrade power usage. Yes, absolutely. Note though that with the iPhone, Apple has decided that the only background services that will be allowed is audio, VOIP, location/navigation, and push notifications. iOS developers don't get access to anything else, and the argument is that nothing else is really *needed*. Android is more flexible in that it allows for non-Apple developers to create new background services, but it's not clear how many you really *need*. This goes back to your first assertion that there are *many* applications that need to run in the background. I just don't think that's true. There will be a few, and probably more than just the restricted set allowed (and programmed) by Apple. But not *many*. - Ted P.S. Although you won't see Apple admitting it, their "fast app switching" is basically what Android has had all along, and most mobile developers are quite happy to call this multi-tasking. Yes, it's not the same as trying to compile the kernel using "make -j 16" in the background. But are you really going to do that on a cell phone battery? I think not. -- 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: Matthew Garrett on 8 Aug 2010 12:20 On Sat, Aug 07, 2010 at 10:46:59AM -0400, Theodore Tso wrote: > True, but again, consider the MacBook. If you plug in an iPod, the > machine will wake up for *just* long enough to let the iTunes sync the > iPod, but once its done, the machine goes back to sleep again > immediately. I doubt MacOS has something called a "suspend blocker" > which prevents the machine from sleeping until iTunes finished, which > when released, allows the machine to suspend again immediately. But > neither did I see any evidence that it took 30 seconds for some kludgy > polling process to decide that iTunes was done, and to allow the > MacBook to go back to sleep. Clearly, the MacBook allows some > interrupts through, and some USB insert events through, but clearly > not all. (Inserting a USB drive doesn't wake up the laptop; at least, > not for long.) On the contrary, I suspect that it's precisely equivalent to userspace suspend blockers. There's no way to conditionalise USB wakeups - the system comes up when you plug or unplug any USB device. The system is then fully awake and I'd *guess* that ipods are magically exempted in some way, with itunes sending a signal when it's complete in order to allow the suspend policy daemon to trigger a suspend again. > Can we do something as smooth with a Linux desktop? And if not, why > not? (Oh yeah, and wasn't this supposed to be the year of the Linux > Desktop? :-) gnome-power-manager supports applications inhibiting suspend, but right now I suspect that it'll never deal with the case where you resume with the lid closed. It's a simple matter of coding, though. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- 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 8 Aug 2010 13:50 On Sun, Aug 8, 2010 at 6:57 PM, Ted Ts'o <tytso(a)mit.edu> wrote: > On Sun, Aug 08, 2010 at 03:53:52PM +0300, Felipe Contreras wrote: >> >> You are overgeneralizing; there are many applications that run in the >> background, and you want to keep them running even when the display is >> off. > > Really? How many do you really expect will be running at the same > time on a mobile platform with a 800-1000 mWh battery? And what > percentage of the applications that might be in a Android or Moblin or > Maemo app store will have things running in the background? 10%? > 20%? 50%? 80%? At any given time most of the applications are running on the background, how much exactly depends on the platform. In my N900 I can see that at least 90% of the process are running on the background right now. >> You seen to be concentrating on UI-only applications, for those it's >> worth noting that Android provides separate mechanisms for power >> saving. Since Android doesn't have true multi-tasking, the >> applications must serialize their states so that the next time they >> are opened they seem to have not been closed. So, the current active >> UI application can be closed while turning off the display, and >> re-opened later. > > Actually in practice, the process or processes which comprise current > active UI application generally won't actually be killed when you turn > off the display. It *might* happen, if one of the rare backround > applications needs more memory than is available without closing some > of the more recently open applications. In practice, the last 2-3 > most recently used applications are still loaded in memory so you can > switch back and forth between them simply and easily. It is true they > have to be ready to be killed at any time in case their memory is > needed for the currently active application, but that generally does't > happen right away. The design is to keep this transparent to the user > so the user does't have to keep track of how many apps currently > running on the system. My last experience using an Android system was that switching applications wasn't done "simply and easily". But supposing it is, Android's UI is completely different to anything else; you cannot take a GNOME/KDE app and expect it to run on Android. Since UI applications are written for Android anyway, then they should be written with PM in mind, and should not rely on suspend blockers. > In any case, the key thing to keep in mind is that when you deal with > extreme power savings, very often you end up making compromises that > probably make sense for other reasons anyway (such as the small screen > size). It's not at all clear that supporting generalized > multi-tasking applications makes sense just from a screen real-estate > issue and user experience POV, never mind battery lifetime. 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*. Multi-tasking and good PM is possible, and the N900 is a good example. Rather than giving up multi-tasking to see how much longer the battery can last, I would rather like to see how to improve batter life for the multi-tasking case. >> User-space suspend blockers are relevant for background services, and >> as it has been discussed before; suspend blockers (not activating >> them) might actually degrade power usage. > > Yes, absolutely. Note though that with the iPhone, Apple has decided > that the only background services that will be allowed is audio, VOIP, > location/navigation, and push notifications. iOS developers don't get > access to anything else, and the argument is that nothing else is > really *needed*. Android is more flexible in that it allows for > non-Apple developers to create new background services, but it's not > clear how many you really *need*. > > This goes back to your first assertion that there are *many* > applications that need to run in the background. I just don't think > that's true. There will be a few, and probably more than just the > restricted set allowed (and programmed) by Apple. But not *many*. 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. -- 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 8 Aug 2010 14:10 On Sun, Aug 08, 2010 at 03:40:28PM +0300, Felipe Contreras wrote: > On Sat, Aug 7, 2010 at 1:54 AM, Paul E. McKenney > <paulmck(a)linux.vnet.ibm.com> wrote: > > o � � � "Ill-behaved application" AKA "untrusted application" AKA > > � � � �"crappy application". > > > o � � � "PM-driving application" are applications that are permitted > > � � � �to acquire suspend blockers on Android. > > These definitions are wrong. Indeed they are, given the way you quoted small portions of them. ;-) > 1) There are trusted applications that misbehave (the user clicks Yes > when asked about PM permissions) These would be buggy PM-driving applications. Of course, any type of application might have bugs, including PM-driving applications. > 2) There are untrusted applications that are power optimized (The user > clicks No) I did indeed exclude this category by saying "power-optimized applications are those PM-driving applications that have been aggressively tuned to reduce power consumption." The reason I excluded this case is that that there are a number of cases where removing the PM-driving attribute could destroy the power optimization. If you have an example power-optimized application that retains its power-optimized property despite lacking PM-driving privileges, please put it forward. In doing so, please keep two things in mind: 1. The definition of power-optimized is more aggressive than many people are used to -- look at http://lkml.org/lkml/2010/8/4/409 and search for "POWER-OPTIMIZED APPLICATIONS". 2. In a number of the implementations that do not use suspend blockers, -all- applications are in effect PM-driving applications. So it is quite possible that different people are using subtly different flavors of the "PM-driving applications" definition. For example, an Android person might consider a application to be PM-driving only if it is permitted to use suspend blockers, while a Maemo person might consider an application to be PM-driving if it had permission to invoke pm_qos functions. If these two hypothetical people each try to apply their definition of PM-driving to each others' platforms, they will likely have severe problems communicating with each other, right? ;-) But if you do have a good example, perhaps I will need to change my definition of power-optimized application. > The proponents of suspend blockers in user-space have tried to ignore > this fact, but the truth is that PM permissions and power optimization > are orthogonal to each other. In fact, you might have noticed that the proponents of each platform have been quite persistent in shouting past each other from the warmth and security of their own particular viewpoints. ;-) 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 8 Aug 2010 14:10
On Sun, Aug 8, 2010 at 10:40 AM, Felipe Contreras <felipe.contreras(a)gmail.com> wrote: >> This goes back to your first assertion that there are *many* >> applications that need to run in the background. I just don't think >> that's true. There will be a few, and probably more than just the >> restricted set allowed (and programmed) by Apple. But not *many*. > > 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. I think there's some confusion here. The default operating mode for Android is to aggressively reach the lowest possible power state (typically full suspend). suspend blockers are used by applications to inform the system that they are currently doing work which requires immediate processing, so the system will avoid fully suspending until that work is done. You could think of it as setting your laptop power management settings to be "blank screen after 60 seconds, power down 5 seconds after blanking", except that there's also a mechanism for apps to hold off on that power down if they're doing important work, and a lot more ways to wakeup beyond opening the lid or pushing the power button. Straight-forward UI apps don't actually require much special handling -- it's preferable that they do busy-wait on things, but even when power is not an issue, wasting cpu spinning needlessly is frowned upon, so this isn't a special request. There's nothing stopping somebody from writing an Android app that acts as a bridge to X11 apps (embedding an X server, etc) and making it possible for native X11 apps to coexist with the Android composition model. I'm a little surprised nobody has done so, actually. I figured *somebody* would decide that they like their phone but absolutely need to run xclock or something locally as a first class app. The Android app model does say that if you're not in the foreground (from a UI standpoint) you should save your state, as you may be terminated if the system runs low on resources. The system only does this when it has to -- generally when we bottom out on memory. On devices with sufficient memory, it's quite common for many apps to remain resident for days-weeks -- I've seen as many as 45-50 apps running on my nexus one. I am a little puzzled by the assertion that Android lasks "true multitasking", but that's another discussion entirely. We certainly don't lack for many concurrent processes and threads... 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/ |