Attempted summary of suspend-blockers LKML thread, take three
in [Kernel]
|
From: david on 7 Aug 2010 05:50 On Sat, 7 Aug 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. this doesn't require wakelocks or anything else new. all it takes is setting the policy that you don't want anything to run when the lid is closed and a switch to detect the lid being closed. Laptops have been doing this for years. > 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.) note that nothing that I have proposed would wake up a sleeping system. the 'every several seconds' thing that I proposed was that on a system that's fully awake, busy and doesn't want to sleep, there would be a context switch periodically by a privilaged process so that the system would not end up deciding it was idle and halt everything. Now that I think about this more, it's not needed if you want to override this to keep everything running for a significant amount of time, just change the power saving mode from "sleep if a privilaged task isn't running" to "disable suspend". This can be done today by changing the right sysfs value. normal privilaged processes would never need to do this, only gatekeeper daemons that want to let unprivilaged processes run even if no privilaged processes want to run would need to do this (i.e. in the current system, whatever process controls the screen would probably be right) > 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.) the question is what it takes to make an application privilaged like this. what I proposed was to make it possible for the user/admin to select what applications are allowed to keep the system awake. wakelocks require that the application developer decide that they want to keep the system awake as well as the user/admin take your example of a mail client waking up every 15 min. with Android it needs to be privilaged to grab the wakelock while fetching the mail, it also needs to use a privilaged API to set the wakeups to wake it up at those times. with what I proposed all you need to do is to tag the application as power privilaged and then if the application sleeps for 15 min between doing thing the system will wake up every 15 min, work for a short time, then go back to sleep. if you want to put everything to sleep when the screen blanks, that's trivial to do. the fun starts when you want to say that there are some things you don't want to put to sleep. do you let some processes run while halting others? in which case how do you prevent deadlocks? on the other hand, sleeping again is simple, you sleep when there is nothing more to run or do you let wasteful processes run while you are awake? this avoids deadlocks, but how do you decide when to sleep again? Android approaches this by requiring that any program that a user may want to keep running must be modified to use wakelocks. My suggestion was that the system ignore other processes when deciding if the system is idle enough to put to sleep. Yes the Android approach works reasonably well on the phones where everything must currently be custom developed anyway (due to screen and UI constraints), but as Android starts getting used on laptops and other larger devices is that really still the right approach? or would it be better to have something that could use standard software in the privilaged mode? to use your example of a mail client, why should someone not be able to use fetchmail to get their mail instead of requiring that fetchmail be modified to use wavelocks (or a substatute written)? the theoretical best approach would probably look nothing like either of these. Instead it would probably either forbid privilaged processes from having blocking dependancies on unprivilaged processes (you can then just halt the unprivilaged processes when you blank the screen and let idle sleep deal with the privilged processes) or use something like priority inheritance through userspace so that if a privilaged process blocks on something where it's waiting for an unprivilaged process, that unprivilaged process gets woken up and allowed to run until it unblocks the privilaged process. both of these have been deemed too hard 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: Alan Stern on 7 Aug 2010 09:30 On Fri, 6 Aug 2010 david(a)lang.hm wrote: > >> 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? Nothing much. Mainly just the fact that Rafael's code is so new. It hasn't yet been integrated into the drivers that should use it. > > 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. Android's wakelock implementation does make wakelocks available to userspace. In Rafael's approach there is nothing comparable. Instead "userspace wakelock"-equivalents have to be handled by a power manager program. > 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? This thread started when Paul posted his list of requirements for Android power management (or power management in general). It wasn't really specific to wakelocks, but people brought them up when discussing how those requirements are currently being met. In fact, it seems to me that _you_ are the person most responsible for prolonging this discussion. > 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. The solution is still in its early stages, and it hasn't yet been accepted into Android. Things will improve over time. (Or they won't, and Android will continue to go its separate way...) > > 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. That's not a difference; it is their decision. For all you or I know, other platforms have been doing the same thing for years. > 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. You are mistaken. Or at best, you are overgeneralizing. It may be true now that all other suspend implementations always go to the same state, but there is no requirement that they do so. > >> 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? I think you should ask them instead of asking me. > 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. This may be controversial, but I think Rafael will agree when I say that (in this one respect) Linus was wrong. Separating hibernation from suspend makes sense, and I agree that the differences between deepest idle and suspend should be minimized. But to get rid of them altogether would be wrong (and probably not possible anyway). > 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. I disagree. There are critical differences between them: Suspend uses the freezer and idle doesn't. Suspend generally forces devices to go into their low-power states immediately, whereas idle tends to leave unused devices at full power for some time before going to low power (to minimize average latency). Overall, suspend generally has longer latency than idle. (This varies among platforms.) The set of wakeup sources (including timers) is different. On some systems, suspend uses platform-specific mechanisms to go into lower power states than are available to idle. There may be others I have left out. 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: Theodore Tso on 7 Aug 2010 10:50 On Aug 7, 2010, at 5:11 AM, Rafael J. Wysocki wrote: > 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. 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.) 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? :-) -- 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: Paul E. McKenney on 7 Aug 2010 11:40 On Sat, Aug 07, 2010 at 02:38:35AM -0700, david(a)lang.hm wrote: > On Sat, 7 Aug 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. > > this doesn't require wakelocks or anything else new. all it takes is > setting the policy that you don't want anything to run when the lid > is closed and a switch to detect the lid being closed. Laptops have > been doing this for years. Please re-read Ted's paragraph above, but carefully this time. You will then see that the desired policy is -not- "you don't want anything to run when the lid is closed." > >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.) > > note that nothing that I have proposed would wake up a sleeping > system. the 'every several seconds' thing that I proposed was that > on a system that's fully awake, busy and doesn't want to sleep, > there would be a context switch periodically by a privilaged process > so that the system would not end up deciding it was idle and halt > everything. Now that I think about this more, it's not needed if you > want to override this to keep everything running for a significant > amount of time, just change the power saving mode from "sleep if a > privilaged task isn't running" to "disable suspend". This can be > done today by changing the right sysfs value. normal privilaged > processes would never need to do this, only gatekeeper daemons that > want to let unprivilaged processes run even if no privilaged > processes want to run would need to do this (i.e. in the current > system, whatever process controls the screen would probably be > right) > > >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.) > > the question is what it takes to make an application privilaged like this. > > what I proposed was to make it possible for the user/admin to select > what applications are allowed to keep the system awake. The Android guys do the same. > wakelocks require that the application developer decide that they > want to keep the system awake as well as the user/admin Whereas you require that the application developer redesign/rewrite applications to decide when to keep the system awake, e.g., by carefully determining when to idle themselves. The difference is that the Android developer need only release a suspend blocker. In contrast, you are requiring that the developer rewrite all the code that follows the point where the Android developer would release a suspend blocker. Your way seems to require that the developer do more work for the same result. Why? Now, I do agree that a safe way to freeze the power-oblivious applications could be valuable, as it might reduce power consumption while the screen was blanked but while a PM-driving application was holding a suspend blocker. However, as we have discussed, you have to be very careful not to freeze any app holding a user-level resource. > take your example of a mail client waking up every 15 min. > > with Android it needs to be privilaged to grab the wakelock while > fetching the mail, it also needs to use a privilaged API to set the > wakeups to wake it up at those times. > > with what I proposed all you need to do is to tag the application as > power privilaged and then if the application sleeps for 15 min > between doing thing the system will wake up every 15 min, work for a > short time, then go back to sleep. > > > if you want to put everything to sleep when the screen blanks, > that's trivial to do. > > the fun starts when you want to say that there are some things you > don't want to put to sleep. Which is in fact a critical requirement that you appear to have been ignoring in your words above. > do you let some processes run while halting others? > in which case how do you prevent deadlocks? > on the other hand, sleeping again is simple, you sleep when > there is nothing more to run > or do you let wasteful processes run while you are awake? > this avoids deadlocks, but how do you decide when to sleep again? > > > Android approaches this by requiring that any program that a user > may want to keep running must be modified to use wakelocks. > > My suggestion was that the system ignore other processes when > deciding if the system is idle enough to put to sleep. But your suggestion seems to require quite a bit more coding effort for little gain. The Android developer can just release a suspend blocker, and in contrast, a developer using your proposal needs to rewrite all the code following the point at which the Android developer released the suspend blocker. So why are you saying that your is approach better? ;-) > Yes the Android approach works reasonably well on the phones where > everything must currently be custom developed anyway (due to screen > and UI constraints), but as Android starts getting used on laptops > and other larger devices is that really still the right approach? or > would it be better to have something that could use standard > software in the privilaged mode? > > to use your example of a mail client, why should someone not be able > to use fetchmail to get their mail instead of requiring that > fetchmail be modified to use wavelocks (or a substatute written)? > > > > the theoretical best approach would probably look nothing like > either of these. Instead it would probably either > > forbid privilaged processes from having blocking dependancies on > unprivilaged processes (you can then just halt the unprivilaged > processes when you blank the screen and let idle sleep deal with the > privilged processes) > > or > > use something like priority inheritance through userspace so that if > a privilaged process blocks on something where it's waiting for an > unprivilaged process, that unprivilaged process gets woken up and > allowed to run until it unblocks the privilaged process. > > both of these have been deemed too hard And for good reason. 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 7 Aug 2010 16:40
On Sat, 7 Aug 2010, Theodore Tso wrote: > On Aug 7, 2010, at 5:11 AM, Rafael J. Wysocki wrote: > >> 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. > 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. nobody has proposed a polling process to decide the system can suspend, what I proposed was to have idle detection decide the system can suspend, which would mean that if you don't want the system to suspend you have to do something to keep it from being idle. At the time I didn't know that Android always disabled suspend for the entire time the display was on, so I made the assumption that timouts had to be long enough for input events to keep the system awake, which would put them on the order of 30 seconds or longer. If all that is wanted is to disable the suspend for the entire time the backlight is on you don't need wakelocks, and you don't need a privilaged thread waking up, all you need is to tell the power management system not to suspend through the existing mechanism. you could create a new mechanism (wakelock) to pass the same information, but what is the advantage of doing so? 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/ |