Attempted summary of suspend-blockers LKML thread
in [Kernel]
|
Prev: [PATCH 6/7] usb: iowarrior: fix misuse of return value of copy_to_user()
Next: Get Back To Me Immediately....
From: Arve Hjønnevåg on 4 Aug 2010 19:00 On Wed, Aug 4, 2010 at 3:31 PM, <david(a)lang.hm> wrote: > On Wed, 4 Aug 2010, Matthew Garrett wrote: > >> On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote: >>> >>> On Wednesday, August 04, 2010, Matthew Garrett wrote: >>>> >>>> No! And that's precisely the issue. Android's existing behaviour could >>>> be entirely implemented in the form of binary that manually triggers >>>> suspend when (a) the screen is off and (b) no userspace applications >>>> have indicated that the system shouldn't sleep, except for the wakeup >>>> event race. Imagine the following: >>>> >>>> 1) The policy timeout is about to expire. No applications are holding >>>> wakelocks. The system will suspend providing nothing takes a wakelock. >>>> 2) A network packet arrives indicating an incoming SIP call >>>> 3) The VOIP application takes a wakelock and prevents the phone from >>>> suspending while the call is in progress >>>> >>>> What stops the system going to sleep between (2) and (3)? cgroups don't, >>>> because the voip app is an otherwise untrusted application that you've >>>> just told the scheduler to ignore. >>> >>> I _think_ you can use the just-merged /sys/power/wakeup_count mechanism >>> to >>> avoid the race (if pm_wakeup_event() is called at 2)). >> >> Yes, I think that solves the problem. The only question then is whether >> it's preferable to use cgroups or suspend fully, which is pretty much up >> to the implementation. In other words, is there a reason we're still >> having this conversation? :) It'd be good to have some feedback from >> Google as to whether this satisfies their functional requirements. > > the proposal that I nade was not to use cgroups to freeze some processes and > not others, but to use cgroups to decide to ignore some processes when > deciding if the system is idle, stop everything or nothing. cgroups are just > a way of easily grouping processes (and their children) into different > groups. > That does not avoid the dependency problem. A process may be waiting on a resource that a process you ignore owns. I you ignore the process that owns the resource and enter idle when it is ready to run (or waiting on a timer), you are still effectively blocking the other process. -- Arve Hj�nnev�g -- 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 4 Aug 2010 19:10 On Wed, Aug 04, 2010 at 03:29:25PM -0700, david(a)lang.hm wrote: > On Wed, 4 Aug 2010, Paul E. McKenney wrote: > >On Wed, Aug 04, 2010 at 12:29:36PM -0700, david(a)lang.hm wrote: > >>On Wed, 4 Aug 2010, Matthew Garrett wrote: > >>>On Wed, Aug 04, 2010 at 12:15:59PM -0700, david(a)lang.hm wrote: > >>>>On Wed, 4 Aug 2010, Matthew Garrett wrote: > >>>>>No! And that's precisely the issue. Android's existing behaviour could > >>>>>be entirely implemented in the form of binary that manually triggers > >>>>>suspend when (a) the screen is off and (b) no userspace applications > >>>>>have indicated that the system shouldn't sleep, except for the wakeup > >>>>>event race. Imagine the following: > >>>>> > >>>>>1) The policy timeout is about to expire. No applications are holding > >>>>>wakelocks. The system will suspend providing nothing takes a wakelock. > >>>>>2) A network packet arrives indicating an incoming SIP call > >>>>>3) The VOIP application takes a wakelock and prevents the phone from > >>>>>suspending while the call is in progress > >>>>> > >>>>>What stops the system going to sleep between (2) and (3)? cgroups don't, > >>>>>because the voip app is an otherwise untrusted application that you've > >>>>>just told the scheduler to ignore. > >>>> > >>>>Even in the current implementation (wakelocks), Since the VOIP > >>>>application isn't allowed to take a wakelock, wouldn't the system go to > >>>>sleep immediatly anyway, even if the application gets the packet and > >>>>starts the call? What would ever raise the wakelock to keep the phone > >>>>from sleeping in the middle of the call? > >>> > >>>There's two parts of that. The first is that the voip application is > >>>allowed to take a wakelock - but that doesn't mean that you trust it the > >>>rest of the time. > >> > >>why would you trust it to take a wakelock, but not trust it the rest > >>of the time? > >> > >>in my proposal I'm saying that if you would trust the application to > >>take a wakelock, you instead trust it to be sane in the rest of it's > >>power activity (avoiding polling, etc) and so you consider it for > >>sleep decisions. > > > >The word "trust" does not appear to be helping here. ;-) > > > >The VOIP application acquires a suspend blocker when it needs to prevent > >the system from suspending, and releases that suspend blocker when it > >can tolerate the system suspending. It is important to note that while > >the VOIP application holds the suspend blocker, the system won't suspend > >even if it is completely idle (for example, if the VOIP application uses > >blocking system calls, during the time that the VOIP application is > >waiting for its next event). > > In the terminology I have been using, the VOIP sofware is then > trusted to take the wakelock appropriately, and I'm then saying it > would be in the trusted cgroup Understood, but... > >>>The second is that the incoming network packet causes > >>>the kernel to take a wakelock that will be released once userspace has > >>>processed the network packet. This ensures that at least one wakelock is > >>>held for the entire relevant period of time. > >> > >>how do you determine that userspace has processed the network packet > >>so that the kernel can release the wakelock (or is this one of the > >>cases where there is a timer related to the wakelock) > > > >There are two cases: > > > >1. The application is permitted to acquire suspend blockers. > > In this case, the application would acquire a suspend blocker > > before reading the input. It would then read the input (at > > which point the kernel releases its suspend blocker), do any > > needed processing, and finally release the suspend blocker. > > > > So in this case, the system knows that the application is > > done processing the input when that application releases > > its suspend blocker. > > in my proposal, the application is trusted to take the wakelock, so > it would be trusted to not use the CPU wildly inappropriatly and so > it running would make the system active and so it would not sleep. .... here you seem to be assuming that "trusted to properly use a wakelock" implies "coded to optimize power usage when not holding a wakelock." But this does not necessarily follow. > >2. The application is prohibited from acquiring suspend blockers. > > In this case, the system might well be suspended before the > > application has a chance to do more than read the input. > > > > But the application will get a chance to process the input > > when the next input event is directed to it. > > In this case the system would go ahead and suspend, but the next > time the sustem wakes up for any reason, this application would > continue to run and process the input Yep, that is in fact what I said. ;-) > >>two things here, > >> > >>on the dirty networks that I see as common, refusing to sleep if > >>network packets are arriving will mean that you never go to sleep. > >> > >>secondly, nothing stops the code doing the idle/suspend decision > >>from considering network activity. I would be surprised if there > >>weren't already options to support this today. > > > >I don't know about the general networking case for Android, but the > >example of downloading was discussed some time back. The application > >doing the download acquires a suspend blocker, which it releases once > >the download is complete (or once a timeout expires, if I remember > >correctly). In this particular case, the network packets were not > >bringing the device out of suspend. > > it would seem reasonable to say that if a packet arrives for an > existing connection (which the kernel does know) it is considered > activity for purposes of sleeping. That would be up to the people creating the system in question. In some cases, they might (as you say) want every packet arriving to wake up the system, in other cases they might not. We should not be taking that design decision away from them. > I don't know if you would care enough to try and say that packets > for untrusted apps network connections don't keep the system awake, > or just allow them to (after all, keypresses going to untrusted apps > do keep the system awake) Again, this is up to the people creating the system in question. On some Android systems, there is a particular button you have to press to wake the system up after it has suspended itself. > >There might well be other cases where networking packets -do- bring > >the system out of suspend, but I must leave this to someone who knows > >more about Android than do I. > > this would be the normal wake-on-lan type of functionality that > exists without Android. Although this wake-on-LAN functionality applies only to special wake-up packets, not to normal packets, right? Thanx, Paul > The primary thing that I was getting at was the other things above. > > 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 4 Aug 2010 19:10 On Wed, 4 Aug 2010, Rafael J. Wysocki wrote: > Subject: Re: Attempted summary of suspend-blockers LKML thread > > On Wednesday, August 04, 2010, david(a)lang.hm wrote: >> On Wed, 4 Aug 2010, Rafael J. Wysocki wrote: >>> In the suspend case, when you have frozen all applications, you can >>> sequentially disable all interrupts except for a few selected ("wakeup") ones >>> in a safe way. By disabling them, you ensure that the CPU will only be >>> "revived" by a limited set of events and that allows the system to stay >>> low-power for extended time intervals. >> >> the benifit of this will depend on what wakeups you are able to avoid by >> putting the hardware to sleep. Depending on the hardware, this may be not >> matter that much. > > That's correct, but evidently it does make a difference with the hardware > Android commonly runs on. Ok, but is there a way to put some of this to sleep without involving a full suspend? >> In addition, there are input devices like a touchscreen that could be >> disabled even short of a full suspend, as long as there is some way to get >> them reactivated. > > That's correct again, but it doesn't matter too much as far as the difference > between "deep idle" and suspend is concerned. These devices are generally not > the interrupt sources that are difficult to shut down safely in the "idle" case. > >>> To achieve the same result in the "idle" case, you'll need to have a mechanism >>> to disable interrupts (except for the "wakeup" ones) avoiding synchronization >>> problems (eg. situations in which task A, blocked on a "suspended" device >>> access, holds a mutex waited for by task B that needs to run so that we can >>> "suspend" another device). That, however, is a difficult problem. >> >> I would say that the difficulty of the problem depends on the hardware and >> how much userspace interaction is needed. If the kernel can disable the >> hardware in the driver (so that it can wake it up again when accessed by >> an application) it would seem that this isn't a problem. > > Well, I guess it's useful to consider the sequence of events in the "idle" > case. > > We first detect that a CPU is idle, so it can be put into a C-state (or > equivalent). It's easy to put that CPU into such a state, but suppose we > want to do more and put all devices into low-power states at that point. > We have to ensure that there are no devices in the middle of DMA and that > the other CPUs are idle (that's kind of easy, but still). Next, we have to > figure out the right ordering in which to put devices into low-power states > (that is not trivial, because the tasks that use those devices may depend on > each other in various ways). If we decide to shut down clock source > interrupts, we must ensure that the timekeeping will be correct after that and > so on. Moreover, things get ugly if there are shared interrupts. > > Suspend kind of works around these difficulties by taking the entire user > space out of the picture with one big sledgehammer called the freezer, > but these problems would have to be actually _solved_ in the "idle" case. I'm not opposed to doing a suspend if the system is idle enough, I'm just questioning if suspend is really that different, or if it can be viewed as yet another low power mode (one that's significantly more expensive to transition in and out of) 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: Anca Emanuel on 4 Aug 2010 19:20 One suggestion: Get an Android Phone, test your ideas on it, then comment. -- 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 4 Aug 2010 19:20
On Wed, 4 Aug 2010, Paul E. McKenney wrote: > On Wed, Aug 04, 2010 at 03:29:25PM -0700, david(a)lang.hm wrote: >> On Wed, 4 Aug 2010, Paul E. McKenney wrote: >>> On Wed, Aug 04, 2010 at 12:29:36PM -0700, david(a)lang.hm wrote: >>>> On Wed, 4 Aug 2010, Matthew Garrett wrote: >>>>> >>>>> There's two parts of that. The first is that the voip application is >>>>> allowed to take a wakelock - but that doesn't mean that you trust it the >>>>> rest of the time. >>>> >>>> why would you trust it to take a wakelock, but not trust it the rest >>>> of the time? >>>> >>>> in my proposal I'm saying that if you would trust the application to >>>> take a wakelock, you instead trust it to be sane in the rest of it's >>>> power activity (avoiding polling, etc) and so you consider it for >>>> sleep decisions. >>> >>> The word "trust" does not appear to be helping here. ;-) >>> >>> The VOIP application acquires a suspend blocker when it needs to prevent >>> the system from suspending, and releases that suspend blocker when it >>> can tolerate the system suspending. It is important to note that while >>> the VOIP application holds the suspend blocker, the system won't suspend >>> even if it is completely idle (for example, if the VOIP application uses >>> blocking system calls, during the time that the VOIP application is >>> waiting for its next event). >> >> In the terminology I have been using, the VOIP sofware is then >> trusted to take the wakelock appropriately, and I'm then saying it >> would be in the trusted cgroup > > Understood, but... > >> it would be trusted to not use the CPU wildly inappropriatly and so >> it running would make the system active and so it would not sleep. > > ... here you seem to be assuming that "trusted to properly use a wakelock" > implies "coded to optimize power usage when not holding a wakelock." > But this does not necessarily follow. I am saying that 'trusted to use a wakelock' does imply 'trusted to not waste power' I am sure that there are apps that do not manage power effectivly, but I don't expect that giving those same developers wakelock power will make them do much better. I expect that any time they discover the system going to sleep on them, they will just add another wakelock to keep it awake. If they were the type to carefully consider what was really important and what wasn't, I would expect them to write fairly power efficiant code in the first place. >>> 2. The application is prohibited from acquiring suspend blockers. >>> In this case, the system might well be suspended before the >>> application has a chance to do more than read the input. >>> >>> But the application will get a chance to process the input >>> when the next input event is directed to it. >> >> In this case the system would go ahead and suspend, but the next >> time the sustem wakes up for any reason, this application would >> continue to run and process the input > > Yep, that is in fact what I said. ;-) so the systems are pretty much equivalent from this point of view. >>>> two things here, >>>> >>>> on the dirty networks that I see as common, refusing to sleep if >>>> network packets are arriving will mean that you never go to sleep. >>>> >>>> secondly, nothing stops the code doing the idle/suspend decision >>>> from considering network activity. I would be surprised if there >>>> weren't already options to support this today. >>> >>> I don't know about the general networking case for Android, but the >>> example of downloading was discussed some time back. The application >>> doing the download acquires a suspend blocker, which it releases once >>> the download is complete (or once a timeout expires, if I remember >>> correctly). In this particular case, the network packets were not >>> bringing the device out of suspend. >> >> it would seem reasonable to say that if a packet arrives for an >> existing connection (which the kernel does know) it is considered >> activity for purposes of sleeping. > > That would be up to the people creating the system in question. In > some cases, they might (as you say) want every packet arriving to > wake up the system, in other cases they might not. We should not > be taking that design decision away from them. well, if you have the kernel take a wakelock when the packet arrives, you are doing the equivalent thing. >> I don't know if you would care enough to try and say that packets >> for untrusted apps network connections don't keep the system awake, >> or just allow them to (after all, keypresses going to untrusted apps >> do keep the system awake) > > Again, this is up to the people creating the system in question. On > some Android systems, there is a particular button you have to press > to wake the system up after it has suspended itself. note that here I am talking about thigns that will keep the system awake, not wake it up after it suspends. >>> There might well be other cases where networking packets -do- bring >>> the system out of suspend, but I must leave this to someone who knows >>> more about Android than do I. >> >> this would be the normal wake-on-lan type of functionality that >> exists without Android. > > Although this wake-on-LAN functionality applies only to special > wake-up packets, not to normal packets, right? that's not my understanding. my understanding (which could be flawed) is that wake-on-lan programs your IP into the NIC and if the NIC sees traffic for you it will wake you up. I've never had a reason to use it, so I could easily be mistaken. 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/ |