Attempted summary of suspend-blockers LKML thread, take three
in [Kernel]
|
From: Alan Stern on 6 Aug 2010 22:50 On Fri, 6 Aug 2010 david(a)lang.hm wrote: > From this discussion, it looks to me like Android wants two key features > that they don't see a way to get today I have largely kept out of this discussion, but this was so outrageous I had to say something. > 1. the ability to decide to suspend while there are still some > 'unimportant' apps running. While this may be true in some literal sense, it certainly is not the best way to view the situation. Linux already has the ability to suspend (or to decide to suspend) whenever you want. What Android has added is the ability to suspend conditionally, based on whether or not some applications or drivers want to keep the system running. Furthermore, this statement leaves out the primary purpose of wakelocks: to avoid races between suspending and wakeup events. And it also ignores a very important distinction: the difference between drivers and applications. Wakelocks are used by both, but it has been shown that only the wakelocks used by drivers need to be implemented in the kernel -- the others can be implemented entirely in userspace. All of these issues are addressed by Raphael's new wakeup_events code. > 2. changes to idle/suspend so that they can get into a state of lower > power consumption thatn any existing idle state (by being able to disable > clocks), but still have some parts of the system powered (so that they are > more awake than suspend) This is nonsense. Nothing was changed. Instead, Android implemented system suspend on their platform in a way that would leave some devices running while the rest of the system powered down. There's nothing out of the ordinary about this. Platforms are free to implement system suspend in whatever way they deem most appropriate. On modern PCs, the most appropriate technique is to go into ACPI's S3 or S4 state. On embedded systems, the technique will vary from one platform to another. > If these two features were available, I think that the rest of what they > are looking for could be built up without requireing other changes. They already _are_ available. Admittedly, only since quite recently. (Rafael's new code was accepted during the 2.6.36 merge window.) > In addition to these key features, the fact that they use suspend much > more frequently means that the race condition between deciding to freeze > and wake events happening is far more likely to cause them problems, so > improvements in this area are needed. I don't think that there is any > fundamental opposition to these improvements, just questions on how best > to do it without causing performance problems. By now, I think most of these questions have been answered. On a slightly different tack, I have noticed that email discussions concerning Android's wakelocks tend to evolve (I almost wrote "devolve") along one of two paths: Either they start talking about ways to integrate Android's goals into the mainline kernel, or else they start complaining about the fact that Android uses system suspend so aggressively and try to find ways to use deep-idle to achieve equivalent results. Although the second path generally ends up being much less productive than the first, it is the one that most discussions seem to end up taking. Large portions of _this_ thread have tended in that direction. Alan Stern -- 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 6 Aug 2010 23:10 On Fri, 6 Aug 2010, Alan Stern wrote: > On Fri, 6 Aug 2010 david(a)lang.hm wrote: > >> From this discussion, it looks to me like Android wants two key features >> that they don't see a way to get today > > I have largely kept out of this discussion, but this was so outrageous > I had to say something. sorry for misunderstanding things, thank you for speaking up to correct the misunderstanding. >> 1. the ability to decide to suspend while there are still some >> 'unimportant' apps running. > > While this may be true in some literal sense, it certainly is not the > best way to view the situation. Linux already has the ability to > suspend (or to decide to suspend) whenever you want. What Android has > added is the ability to suspend conditionally, based on whether or not > some applications or drivers want to keep the system running. Ok, aside from possibly drivers, what' stopping this from being done on a valilla system today? > Furthermore, this statement leaves out the primary purpose of > wakelocks: to avoid races between suspending and wakeup events. And it > also ignores a very important distinction: the difference between > drivers and applications. Wakelocks are used by both, but it has been > shown that only the wakelocks used by drivers need to be implemented in > the kernel -- the others can be implemented entirely in userspace. Ok, this is the first I've heard in this discussion that wakelocks would not be available to userspace. In fact it was explicitly stated that userspace applications called IOCTLs to get/release the wakelock. many of my objections (voiced in another thread) about Android specific features are not relavent if the wakelock in userspace is just part of that application framework and not tied into the kernel. > All of these issues are addressed by Raphael's new wakeup_events code. Ok, then why is there still discussion about wakelocks at all if Raphael has implemnetd the needed kernel functionality and userspace is Android SDK specific? the heated replys from some people about what Android needs (from people who I assumed were Android maintainers due to the way they were answering questions) sure didn't sound like this was a solved problem. >> 2. changes to idle/suspend so that they can get into a state of lower >> power consumption thatn any existing idle state (by being able to disable >> clocks), but still have some parts of the system powered (so that they are >> more awake than suspend) > > This is nonsense. Nothing was changed. Instead, Android implemented > system suspend on their platform in a way that would leave some devices > running while the rest of the system powered down. There's nothing out > of the ordinary about this. Platforms are free to implement system > suspend in whatever way they deem most appropriate. On modern PCs, the > most appropriate technique is to go into ACPI's S3 or S4 state. On > embedded systems, the technique will vary from one platform to another. the difference is that not all suspends on Android are the same, sometimes when you suspend you power down the audio components, sometimes you don't. As far as I am aware (and please correct meif I am mistaken), this is significantly different from suspend elsewhere where suspend always takes you to the same state. >> If these two features were available, I think that the rest of what they >> are looking for could be built up without requireing other changes. > > They already _are_ available. Admittedly, only since quite recently. > (Rafael's new code was accepted during the 2.6.36 merge window.) Do Brian and Arve agree that this solves their problem? >> In addition to these key features, the fact that they use suspend much >> more frequently means that the race condition between deciding to freeze >> and wake events happening is far more likely to cause them problems, so >> improvements in this area are needed. I don't think that there is any >> fundamental opposition to these improvements, just questions on how best >> to do it without causing performance problems. > > By now, I think most of these questions have been answered. > > On a slightly different tack, I have noticed that email discussions > concerning Android's wakelocks tend to evolve (I almost wrote > "devolve") along one of two paths: Either they start talking about ways > to integrate Android's goals into the mainline kernel, or else they > start complaining about the fact that Android uses system suspend so > aggressively and try to find ways to use deep-idle to achieve > equivalent results. Although the second path generally ends up being > much less productive than the first, it is the one that most > discussions seem to end up taking. Large portions of _this_ thread > have tended in that direction. to be fair, there have been numerous complaints about suspend being separate from deep sleep long before Android. Linus' blow-up that resulted in Hibernation and Suspend being separated from each other is a case in point. He was making the point that there shouldn't be a difference between the deepest sleep and suspend. As deep sleep gains the ability to use even less power and as suspend gains the ability to leave things on sometimes, the difference between them is dissapearing. I wouldn't be at all surprised to see them start overlaping soon. So it's not that I think Android should use deep sleeps instead of suspend, but rather that suspend should just be the deepest sleep, one mechanism instead of two. 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: david on 6 Aug 2010 23:20 On Fri, 6 Aug 2010, Brian Swetland wrote: > On Fri, Aug 6, 2010 at 4:59 PM, <david(a)lang.hm> wrote: >> >> now, android is betting that the apps are all developed specifically for the >> android from scratch, so having a different API is acceptable, even if it >> cuts them off from the rest of the *nix applications. For a phone this is >> not neccessarily an unreasonable stance, but as Android moves into the >> spaces where normal applications are in use (netbooks and tablets), this >> becomes a much shakier stance to take. > > "Normal" apps work reasonably well -- they get halted when the screen > turns off, just like they do when my laptop suspends. > > Wakelocks are useful for mobile-centric apps that you want to keep > running in the background, wake up and do work when the device is > "asleep", etc. that description sounds far more like normal sleep power management that suspending. especially since they want to set timers to wake the system up and the defining characteristic of suspend (according to this thread) is that timers don't fire while suspended. as I am seeing it, there are two reasons why this don't "just work" 1. sleeping can't currently save as much power as suspending 2. the current logic for deciding to sleep can't ignore the other apps on the system. 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: Ted Ts'o on 7 Aug 2010 02:20 On Fri, Aug 06, 2010 at 08:14:09PM -0700, david(a)lang.hm wrote: > > that description sounds far more like normal sleep power management > that suspending. especially since they want to set timers to wake > the system up and the defining characteristic of suspend (according > to this thread) is that timers don't fire while suspended. > > as I am seeing it, there are two reasons why this don't "just work" > > 1. sleeping can't currently save as much power as suspending No, I don't think that's the case at all. The key thing here is that *most* applications don't need to be modified to use suspend locks, because even though they might be in an event loop, when the user user turns off the display, the user generally doesn't want it doing things on their behalf. Again, take for example the Mac Book, since Apple has gotten this right for most users' use cases. When you close the lid, you even if the application is under the misguided belief that it should be checking every five seconds to see whether or not the web page has reloaded --- actually, that's not what you want. You probably want the application to be forcibly put to sleep. So the whole point of the suspend blocker design is that you don't have to modify most applications; they just simply get put to sleep when you close the MacBook lid, or, in the case of the Android device, you push the button that turns off the screen. So the reason why this doesn't work is that power management for small mobile devices *is* different from power management for laptops and data center servers, and if you want a rich application ecosystem, it's best if you don't require them to be specially tuned to use the absolute minimum power. (And that means waking up every 30 seconds might be too much; as Brian and Arve have pointed out, with the G1 in airplane mode, the CPU might be waking up once every half hour or more --- and at that rate, powertop will be waking up the CPU more than Android system would be doing so.) So the real key here is to take most applications, which may be written using techniques that might be considered well written from a laptop point of view, but not for a cell phone, and not require modifications. Even though the application writer might think it's doing well by waking up every 15 seconds, if the laptop lid is down, or if the screen is off, for **most** applications, it should be forcibly put to sleep. It's only the rare applications that should really be allowed to run while screen is off. And it's only those applications that need modifications to use suspend blocker. From your earlier comments, it seems that this is the key point which you are missing. (No doubt, some of these applications that do need to know about suspend blockers are important ones; ones that make sure the battery isn't about to blow up, or ones which silently wake up every 10-15 minutes to pull down fresh mail for you from your mail server. But those applications are the exception, not the rule.) Best regards, - Ted -- 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: Rafael J. Wysocki on 7 Aug 2010 05:20
On Saturday, August 07, 2010, Rafael J. Wysocki wrote: > On Saturday, August 07, 2010, Ted Ts'o wrote: > > On Fri, Aug 06, 2010 at 08:14:09PM -0700, david(a)lang.hm wrote: > > > > > > that description sounds far more like normal sleep power management > > > that suspending. especially since they want to set timers to wake > > > the system up and the defining characteristic of suspend (according > > > to this thread) is that timers don't fire while suspended. > > > > > > as I am seeing it, there are two reasons why this don't "just work" > > > > > > 1. sleeping can't currently save as much power as suspending > > > > No, I don't think that's the case at all. The key thing here is that > > *most* applications don't need to be modified to use suspend locks, > > because even though they might be in an event loop, when the user user > > turns off the display, the user generally doesn't want it doing things > > on their behalf. > > > > Again, take for example the Mac Book, since Apple has gotten this > > right for most users' use cases. When you close the lid, you even if > > the application is under the misguided belief that it should be > > checking every five seconds to see whether or not the web page has > > reloaded --- actually, that's not what you want. You probably want > > the application to be forcibly put to sleep. So the whole point of > > the suspend blocker design is that you don't have to modify most > > applications; they just simply get put to sleep when you close the > > MacBook lid, or, in the case of the Android device, you push the > > button that turns off the screen. > > But in principle that need not mean suspending the entire system. > To get applications out of the way, you need to freeze user space. > However, that's not sufficient, because in addition to that you need to > prevent deactivate the majority of interrupt sources to avoid waking up the > CPU (from C-states) too often. s/prevent deactivate/deactivate/ Rafael -- 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/ |