Attempted summary of suspend-blockers LKML thread, take three
in [Kernel]
|
From: david on 7 Aug 2010 17:10 On Sat, 7 Aug 2010, Alan Stern wrote: > 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. makes sense. >>> 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. And the question to the Android people is if they consider this acceptable or think that this means that the vanilla can't support them. >> 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. I'll admit to that, but it seems like there is still new information comeing up about the requirements, as well as the current implementation. >>>> 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. Since they are following this thread, this was intended to be asking them torespond. >> 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). if you thing the differences should be minimized, why do you think that getting rid of them would be wrong? I know that Rafael disagrees with Linus, because he has not implemented what Linus suggested. >> 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). this sounds like policy, not capability. > Overall, suspend generally has longer latency than idle. (This > varies among platforms.) even different idle modes have different latency > The set of wakeup sources (including timers) is different. I agree that they are different, but don't they also vary within sleep or suspend as well? > On some systems, suspend uses platform-specific mechanisms to > go into lower power states than are available to idle. the exact mechanism to go into low-power states is platform specific to start with (there are some very popular platforms admittedly, like the PC ACPI modes) as I see it Sleep a policy engine to decide when to sleep, how deeply to sleep, what to disable, what will wake you up (this includes taking into account desired latency, and the amount of power/time needed to get in and out of the various modes) platform specific mechanisms for transitioning in and out of the modes. Suspend a policy engine to decide when to suspend, what to leave enabled when you supend, what will wake you i[ platform specific mechanisms for transition in and out of suspend. I view use of the freezer to be one of these mechansims. Somewhere amoung this mess are things like spinning down drives, disabling inactive network interfaces, etc. I don't knwo if those are run from the sleep policy engine, or if there is a third policy engine to decide these things. why should there be multiple different policy engines making power management decisions? it seems to me like these policy engines can and should be merged, with the resulting engine able to trigger all the existing mechanisms for transitioning between modes. 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 7 Aug 2010 17:30 On Sat, 7 Aug 2010, Paul E. McKenney wrote: > 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: >> >>> 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? portability, and the fact that it will save more power even when the system is prevented from suspending. >> 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. I admit that the way I wrote this is confusing, but I don't think I am ignoring this requirement. the example above was how an application that the system is not wanting to put to sleep would run with the two mechansims. >> 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? ;-) no, the coder needs to make his code not do unnessasary things. Even with a wakelock this is needed for the system to be able to use lower power modes while the system is not going to do a suspend anyway. I am say that if the coder does that, the coder should not also have to code in wakelocks. I want it to be as easy as possible to port applications between mobile platforms. On most platforms wakelocks are not needed because standard idle/sleep/suspend mechanisms are good enough. Android allows other applications to run that confuse the idle/sleep/suspend mechanisms, so something needs to be done to cut through the confusion. Android does this by creating a new API to control this, I'm suggesting that there should be a way to tell the system to ignore the other applications so that the existing mechanisms can make good decisions again. 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 8 Aug 2010 08:50 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. 1) There are trusted applications that misbehave (the user clicks Yes when asked about PM permissions) 2) There are untrusted applications that are power optimized (The user clicks No) 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. -- 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 8 Aug 2010 09:00 On Sat, Aug 7, 2010 at 9:15 AM, Ted Ts'o <tytso(a)mit.edu> wrote: > On Fri, Aug 06, 2010 at 08:14:09PM -0700, david(a)lang.hm wrote: >> 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. 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. 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. 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. -- 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: Alan Stern on 8 Aug 2010 11:40
On Sat, 7 Aug 2010 david(a)lang.hm wrote: > > 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). > > if you thing the differences should be minimized, why do you think that > getting rid of them would be wrong? Actually I meant that _attempting_ to get rid of them would be wrong, because it would be a futile attempt to carry out an impossible task. > >> 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). > > this sounds like policy, not capability. It isn't. Suspend does not have the capability to leave a device at full power for 100 ms and then switch it to low power if it hasn't been used in that time. (Or, it requires special hardware support to be able to do this.) Idle does have this capability. > > Overall, suspend generally has longer latency than idle. (This > > varies among platforms.) > > even different idle modes have different latency But the difference between idle and suspend can be orders of magnitude larger. That makes it qualitatively different, not just quantitatively different. > > The set of wakeup sources (including timers) is different. > > I agree that they are different, but don't they also vary within sleep or > suspend as well? Suspend _is_ a form of sleep. (The other form is hibernation.) It's true that the set of wakeup sources can be customized to some extent. But in the usual implementations, timers are never a wakeup source for suspend whereas they always are for idle. > > On some systems, suspend uses platform-specific mechanisms to > > go into lower power states than are available to idle. > > the exact mechanism to go into low-power states is platform specific to > start with (there are some very popular platforms admittedly, like the PC > ACPI modes) Sure, the mechanism is platform-specific. That doesn't change the fact that ACPI systems can achieve lower power usage with suspend than they can with idle. > as I see it > > Sleep Do you mean "idle" or "deep-idle" rather than "sleep"? > a policy engine to decide when to sleep, how deeply to sleep, what to > disable, what will wake you up (this includes taking into account desired > latency, and the amount of power/time needed to get in and out of the > various modes) > > platform specific mechanisms for transitioning in and out of the modes. > > > Suspend > > a policy engine to decide when to suspend, what to leave enabled when you > supend, what will wake you i[ Suspend is initiated entirely by userspace, not by the kernel. Wakelocks provide a means for the kernel to delay or cancel a suspend request, not to initiate one. > platform specific mechanisms for transition in and out of suspend. I view > use of the freezer to be one of these mechansims. The freezer is not platform specific. > Somewhere amoung this mess are things like spinning down drives, disabling > inactive network interfaces, etc. I don't knwo if those are run from the > sleep policy engine, or if there is a third policy engine to decide these > things. > > > why should there be multiple different policy engines making power > management decisions? it seems to me like these policy engines can and > should be merged, with the resulting engine able to trigger all the > existing mechanisms for transitioning between modes. There are multiple policy engines because one of them is in the kernel and the other is in userspace. I don't see how you can merge the two. 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/ |