Re: [linux-pm] Runtime PM discussion notes
Hi! Well, auto suspending when screensaver is active would still be useful. (And IIRC some machines kept screen on when in S-state unless driver powered it down... but that might be S1. The reason why you can't enter ACPI S-states from CPUidle is because you need to go out of the idle loop to execute some ACPI-specific stuff. Which is not even specific to Intel chips, but to ACPI in general. The code was little tricky/unclean, but it worked for me at one point... I called it sleepy linux. Yes, you can find a system where it might kind of work (just because _PTS is empty or something like this). Is it going to work in general? No way. IIRC I solved it by just calling _PTS when sleepy Linux was enabled. It had side effect of lighting up moon icon, but otherwise seemed to work ok. I do not think ACPI says what can and can not be done after _PTS... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Runtime PM discussion notes
On Saturday, July 30, 2011, Pavel Machek wrote: Hi! Well, auto suspending when screensaver is active would still be useful. (And IIRC some machines kept screen on when in S-state unless driver powered it down... but that might be S1. The reason why you can't enter ACPI S-states from CPUidle is because you need to go out of the idle loop to execute some ACPI-specific stuff. Which is not even specific to Intel chips, but to ACPI in general. The code was little tricky/unclean, but it worked for me at one point... I called it sleepy linux. Yes, you can find a system where it might kind of work (just because _PTS is empty or something like this). Is it going to work in general? No way. IIRC I solved it by just calling _PTS when sleepy Linux was enabled. It had side effect of lighting up moon icon, but otherwise seemed to work ok. I do not think ACPI says what can and can not be done after _PTS... Yes, it does. Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Runtime PM discussion notes
IIRC I solved it by just calling _PTS when sleepy Linux was enabled. It had side effect of lighting up moon icon, but otherwise seemed to work ok. I do not think ACPI says what can and can not be done after _PTS... Yes, it does. And even if _PTS will work, you're certainly not supposed to execute _WAK with interrupts off. It should be ok to execute _WAK in process context once system is resumed. ... or maybe not executing _WAK at all. User can probably live with moon icon lighted up. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Runtime PM discussion notes
On Saturday, July 30, 2011, Rafael J. Wysocki wrote: On Saturday, July 30, 2011, Pavel Machek wrote: Hi! Well, auto suspending when screensaver is active would still be useful. (And IIRC some machines kept screen on when in S-state unless driver powered it down... but that might be S1. The reason why you can't enter ACPI S-states from CPUidle is because you need to go out of the idle loop to execute some ACPI-specific stuff. Which is not even specific to Intel chips, but to ACPI in general. The code was little tricky/unclean, but it worked for me at one point... I called it sleepy linux. Yes, you can find a system where it might kind of work (just because _PTS is empty or something like this). Is it going to work in general? No way. IIRC I solved it by just calling _PTS when sleepy Linux was enabled. It had side effect of lighting up moon icon, but otherwise seemed to work ok. I do not think ACPI says what can and can not be done after _PTS... Yes, it does. And even if _PTS will work, you're certainly not supposed to execute _WAK with interrupts off. Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Runtime PM discussion notes
On Saturday, July 30, 2011, Pavel Machek wrote: IIRC I solved it by just calling _PTS when sleepy Linux was enabled. It had side effect of lighting up moon icon, but otherwise seemed to work ok. I do not think ACPI says what can and can not be done after _PTS... Yes, it does. And even if _PTS will work, you're certainly not supposed to execute _WAK with interrupts off. It should be ok to execute _WAK in process context once system is resumed. ... or maybe not executing _WAK at all. User can probably live with moon icon lighted up. But I don't think the user can live with certain functionality missing, like battery status or such things. This is completely unrealistic to think that your prototype can be safely implemented on _every_ ACPI-based system. Period. And that's even without taking SMP into account, BTW. Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Runtime PM discussion notes
Hi! IIRC I solved it by just calling _PTS when sleepy Linux was enabled. It had side effect of lighting up moon icon, but otherwise seemed to work ok. I do not think ACPI says what can and can not be done after _PTS... Yes, it does. I have 2.0 spec here; it explains how _PTS can be called long time before actual sleep and may not power down devices... It should be ok to execute _WAK in process context once system is resumed. ... or maybe not executing _WAK at all. User can probably live with moon icon lighted up. But I don't think the user can live with certain functionality missing, like battery status or such things. Yep; you'd probably want to execute it before calling other ACPI methods... This is completely unrealistic to think that your prototype can be safely implemented on _every_ ACPI-based system. Period. My prototype would probably not be safe on any system, period. It was quick hack to prove the concept. And that's even without taking SMP into account, BTW. Idea was to do hot CPU unplug before enabling sleepy state. Sleepy probably should be enabled when screen is turned off by screensaver (if machine is sufficiently idle). I'm not saying that task is easy, merely that is doable. (Doing it in clean way will be harder still). Basically prepare all the devices to sleep when machine gets idle enough, along with _PTS, but keep running, including userspace. Then, if next wake up is long enough into future, set up RTC alarm and push machine to sleep. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Runtime PM discussion notes
On Sunday, July 31, 2011, Pavel Machek wrote: Hi! IIRC I solved it by just calling _PTS when sleepy Linux was enabled. It had side effect of lighting up moon icon, but otherwise seemed to work ok. I do not think ACPI says what can and can not be done after _PTS... Yes, it does. I have 2.0 spec here; it explains how _PTS can be called long time before actual sleep and may not power down devices... It should be ok to execute _WAK in process context once system is resumed. ... or maybe not executing _WAK at all. User can probably live with moon icon lighted up. But I don't think the user can live with certain functionality missing, like battery status or such things. Yep; you'd probably want to execute it before calling other ACPI methods... This is completely unrealistic to think that your prototype can be safely implemented on _every_ ACPI-based system. Period. My prototype would probably not be safe on any system, period. It was quick hack to prove the concept. And that's even without taking SMP into account, BTW. Idea was to do hot CPU unplug before enabling sleepy state. Sleepy probably should be enabled when screen is turned off by screensaver (if machine is sufficiently idle). I'm not saying that task is easy, merely that is doable. (Doing it in clean way will be harder still). Basically prepare all the devices to sleep when machine gets idle enough, along with _PTS, but keep running, including userspace. Then, if next wake up is long enough into future, set up RTC alarm and push machine to sleep. You're supposed to do all that from within the idle loop on one of the CPUs (at least in the context of this discussion). I don't really think it's realistically doable. Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Runtime PM discussion notes
Hi! Actually, it just occurred to me that if we're waiting for a system timer and can hand that off to a suitable timer in the PMIC then we can do a suspend to RAM for the deep idle state from the hardware point of view. Yep. At LinuxCon Cambridge two years ago, we had a discussion about whether it would be possible to enter ACPI S-states from CPUIdle (or some idle governor) on Intel chips. If I remember correctly, the conclusion was that ACPI always disables the screen/backlight, so it would only be useful for situations where that was acceptable. Well, auto suspending when screensaver is active would still be useful. (And IIRC some machines kept screen on when in S-state unless driver powered it down... but that might be S1. The reason why you can't enter ACPI S-states from CPUidle is because you need to go out of the idle loop to execute some ACPI-specific stuff. Which is not even specific to Intel chips, but to ACPI in general. The code was little tricky/unclean, but it worked for me at one point... I called it sleepy linux. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Runtime PM discussion notes
On Friday, July 29, 2011, Pavel Machek wrote: Hi! Actually, it just occurred to me that if we're waiting for a system timer and can hand that off to a suitable timer in the PMIC then we can do a suspend to RAM for the deep idle state from the hardware point of view. Yep. At LinuxCon Cambridge two years ago, we had a discussion about whether it would be possible to enter ACPI S-states from CPUIdle (or some idle governor) on Intel chips. If I remember correctly, the conclusion was that ACPI always disables the screen/backlight, so it would only be useful for situations where that was acceptable. Well, auto suspending when screensaver is active would still be useful. (And IIRC some machines kept screen on when in S-state unless driver powered it down... but that might be S1. The reason why you can't enter ACPI S-states from CPUidle is because you need to go out of the idle loop to execute some ACPI-specific stuff. Which is not even specific to Intel chips, but to ACPI in general. The code was little tricky/unclean, but it worked for me at one point... I called it sleepy linux. Yes, you can find a system where it might kind of work (just because _PTS is empty or something like this). Is it going to work in general? No way. So please let's turn into something at least _theoretically_ viable. Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Runtime PM discussion notes
(cc'ing Len) Hi Mark, On Mon, 11 Jul 2011, Mark Brown wrote: The interesting bits are things like being able to kill lots of the SoC core supplies when the RAM is in retention mode - the CPU needs to go through its shutdown procedures. This is indeed possible on OMAP3+ chips with TWL4030+ PMICs. Probably other PMICs also. TI calls it off-mode. The N900 shipped with this feature enabled. Not sure how many other similar products did. This can be enabled in mainline, but not all of the mainline drivers have context save/restore code merged yet, so in mainline it only works with a subset of drivers. Actually, it just occurred to me that if we're waiting for a system timer and can hand that off to a suitable timer in the PMIC then we can do a suspend to RAM for the deep idle state from the hardware point of view. Yep. At LinuxCon Cambridge two years ago, we had a discussion about whether it would be possible to enter ACPI S-states from CPUIdle (or some idle governor) on Intel chips. If I remember correctly, the conclusion was that ACPI always disables the screen/backlight, so it would only be useful for situations where that was acceptable. To the best of my (limited) knowledge, that's the only case I know of where there's a hardware limitation that prevents dynamic idle from reaching the same low power state as system suspend. If someone has hard details of a similar example, it would be great to know about it. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Runtime PM discussion notes
On Wednesday, July 13, 2011, Paul Walmsley wrote: (cc'ing Len) Hi Mark, On Mon, 11 Jul 2011, Mark Brown wrote: The interesting bits are things like being able to kill lots of the SoC core supplies when the RAM is in retention mode - the CPU needs to go through its shutdown procedures. This is indeed possible on OMAP3+ chips with TWL4030+ PMICs. Probably other PMICs also. TI calls it off-mode. The N900 shipped with this feature enabled. Not sure how many other similar products did. This can be enabled in mainline, but not all of the mainline drivers have context save/restore code merged yet, so in mainline it only works with a subset of drivers. Actually, it just occurred to me that if we're waiting for a system timer and can hand that off to a suitable timer in the PMIC then we can do a suspend to RAM for the deep idle state from the hardware point of view. Yep. At LinuxCon Cambridge two years ago, we had a discussion about whether it would be possible to enter ACPI S-states from CPUIdle (or some idle governor) on Intel chips. If I remember correctly, the conclusion was that ACPI always disables the screen/backlight, so it would only be useful for situations where that was acceptable. The reason why you can't enter ACPI S-states from CPUidle is because you need to go out of the idle loop to execute some ACPI-specific stuff. Which is not even specific to Intel chips, but to ACPI in general. So entering ACPI S-states from idle is a no-no and I don't think it'll change in foreseeable future. To the best of my (limited) knowledge, that's the only case I know of where there's a hardware limitation that prevents dynamic idle from reaching the same low power state as system suspend. If someone has hard details of a similar example, it would be great to know about it. Google G1 had this problem IIRC, but I don't have any details. Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Runtime PM discussion notes
On Mon, Jul 11, 2011 at 02:58:12AM -0700, Tony Lindgren wrote: * Mark Brown broo...@opensource.wolfsonmicro.com [110708 21:01]: At least the Nexus S doesn't implmeent any of the deep idle infrastructure. However, I'd expect that you can achieve some power saving from entering system suspend as if *everything* is off then the PMIC can be suspended which can enable additional power savings. Unless I'm missing something that'd be hard to hit with cpuidle only stuff. You should be able to hit the same states from idle no problem. At that point the only things on are memory in retention and some wake-up timer. Even the timer could be off if you have hardware wake-up events, but then system timer won't work the noral way naturally. Right, but it can be interesting to tell the PMIC that we went into this mode. Possibly cpuidle will end up doing this as a result of signals generated as the CPU core goes down, but at that point it's just s2ram by another name. The only way power down everything in suspend to disk :) Most PMICs have some functionality always on so they can charge the battery when it's empty. With some PMICs the truly always on functionality is *very* minimal and doesn't include chargers, it can be pretty much limited to wake sources (including power status changes which might start charging if power appears). -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Runtime PM discussion notes
* Mark Brown broo...@opensource.wolfsonmicro.com [110711 03:59]: On Mon, Jul 11, 2011 at 02:58:12AM -0700, Tony Lindgren wrote: * Mark Brown broo...@opensource.wolfsonmicro.com [110708 21:01]: At least the Nexus S doesn't implmeent any of the deep idle infrastructure. However, I'd expect that you can achieve some power saving from entering system suspend as if *everything* is off then the PMIC can be suspended which can enable additional power savings. Unless I'm missing something that'd be hard to hit with cpuidle only stuff. You should be able to hit the same states from idle no problem. At that point the only things on are memory in retention and some wake-up timer. Even the timer could be off if you have hardware wake-up events, but then system timer won't work the noral way naturally. Right, but it can be interesting to tell the PMIC that we went into this mode. Possibly cpuidle will end up doing this as a result of signals generated as the CPU core goes down, but at that point it's just s2ram by another name. All PMIC devices should be shut down when not in use, so I don't know what else you would configure in the PMIC. Maybe you have something else there to configure? Just curious what kind of mess you have to deal with compared to the mess I need to deal with :) Also, hitting deeper sleep states from idle is not same as suspend to ram. With suspend to ram the system timer is killed while timers behave in a normal way when hitting deeper sleep states from idle. The only way power down everything in suspend to disk :) Most PMICs have some functionality always on so they can charge the battery when it's empty. With some PMICs the truly always on functionality is *very* minimal and doesn't include chargers, it can be pretty much limited to wake sources (including power status changes which might start charging if power appears). Sure. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Runtime PM discussion notes
On Mon, Jul 11, 2011 at 04:14:24AM -0700, Tony Lindgren wrote: * Mark Brown broo...@opensource.wolfsonmicro.com [110711 03:59]: Right, but it can be interesting to tell the PMIC that we went into this mode. Possibly cpuidle will end up doing this as a result of signals generated as the CPU core goes down, but at that point it's just s2ram by another name. All PMIC devices should be shut down when not in use, so I don't know what else you would configure in the PMIC. Maybe you have something else there to configure? Just curious what kind of mess you have to deal with compared to the mess I need to deal with :) The interesting bits are things like being able to kill lots of the SoC core supplies when the RAM is in retention mode - the CPU needs to go through its shutdown procedures. Also, hitting deeper sleep states from idle is not same as suspend to ram. With suspend to ram the system timer is killed while timers behave in a normal way when hitting deeper sleep states from idle. Actually, it just occurred to me that if we're waiting for a system timer and can hand that off to a suitable timer in the PMIC then we can do a suspend to RAM for the deep idle state from the hardware point of view. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Runtime PM discussion notes
* Mark Brown broo...@opensource.wolfsonmicro.com [110711 04:21]: On Mon, Jul 11, 2011 at 04:14:24AM -0700, Tony Lindgren wrote: * Mark Brown broo...@opensource.wolfsonmicro.com [110711 03:59]: Right, but it can be interesting to tell the PMIC that we went into this mode. Possibly cpuidle will end up doing this as a result of signals generated as the CPU core goes down, but at that point it's just s2ram by another name. All PMIC devices should be shut down when not in use, so I don't know what else you would configure in the PMIC. Maybe you have something else there to configure? Just curious what kind of mess you have to deal with compared to the mess I need to deal with :) The interesting bits are things like being able to kill lots of the SoC core supplies when the RAM is in retention mode - the CPU needs to go through its shutdown procedures. I see. I've seen cases these are pre-programmed to the PMIC and then automatically triggered based on some event like WFI. Also, hitting deeper sleep states from idle is not same as suspend to ram. With suspend to ram the system timer is killed while timers behave in a normal way when hitting deeper sleep states from idle. Actually, it just occurred to me that if we're waiting for a system timer and can hand that off to a suitable timer in the PMIC then we can do a suspend to RAM for the deep idle state from the hardware point of view. Cool, it would be nice to have a Linux generic way for programming a separate hardware wake-up timer. Not RTC, but some more accurate timer that might be too slow to access for general purpose usage. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Runtime PM discussion notes
On Tue, Jun 28, 2011 at 01:47:47PM -0600, Paul Walmsley wrote: On Fri, 24 Jun 2011, Arve Hj?nnev?g wrote: On Fri, Jun 24, 2011 at 12:53 PM, Paul Walmsley p...@pwsan.com wrote: On the hardware that shipped we enter the same power state from idle and suspend, so the only power savings we get from suspend that we don't get in idle is from not respecting the scheduler and timers. This is no longer the case. Both the Nexus-S and Xoom enter lower power states from suspend than idle. Just out of curiosity, is that due to some kind of hardware limitation on those platforms, or is it because the software infrastructure for dynamic deep idle hasn't been fully implemented in that subarchitecture code? At least the Nexus S doesn't implmeent any of the deep idle infrastructure. However, I'd expect that you can achieve some power saving from entering system suspend as if *everything* is off then the PMIC can be suspended which can enable additional power savings. Unless I'm missing something that'd be hard to hit with cpuidle only stuff. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Runtime PM discussion notes
Hello Arve, On Fri, 24 Jun 2011, Arve Hjønnevåg wrote: On Fri, Jun 24, 2011 at 12:53 PM, Paul Walmsley p...@pwsan.com wrote: As I understand it, in the original Android implementation, the hardware that they were using didn't have fine-grained power management. So system-wide suspend made more sense in that context. But that shouldn't be confused with the modern rationale for wakelocks: https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025668.html On the hardware that shipped we enter the same power state from idle and suspend, so the only power savings we get from suspend that we don't get in idle is from not respecting the scheduler and timers. This is no longer the case. Both the Nexus-S and Xoom enter lower power states from suspend than idle. Just out of curiosity, is that due to some kind of hardware limitation on those platforms, or is it because the software infrastructure for dynamic deep idle hasn't been fully implemented in that subarchitecture code? - Paul
Re: [linux-pm] Runtime PM discussion notes
Hi, On Friday, June 24, 2011, Paul Walmsley wrote: (Arve cc'ed, also adding Magnus and Kevin back to cc) Thanks, my mailer is playing tricks on me. :-) Hi Rafael, On Thu, 23 Jun 2011, Rafael J. Wysocki wrote: On Thursday, June 23, 2011, Alan Stern wrote: On Thu, 23 Jun 2011, Paul Walmsley wrote: On Wed, 15 Jun 2011, Rafael J. Wysocki wrote: Well, the freezing of user space by itself doesn't buy you anything power management-wise, you pretty much need to do the other things too to really save energy this way. Freezing user space stops CPU-hogging processes from running. When the runqueue is empty, the scheduler can go idle. This in turn allows the CPU(s) to enter low power sleep states via CPUIdle. But you don't have to freeze user space for this purpose, do you? You may simply send a SIGSTOP to those processes. Probably that would be useful for some use-cases. there are two issues with SIGSTOP/SIGCONT that I'm aware of, compared to freezing: 1. if sent from a userspace process, SIGSTOP/SIGCONT are potentially racy with respect to system calls like setsid(), such that the sender may miss some processes; I must admit I don't know the details here, but that sounds quite plausible. 2. SIGSTOP/SIGCONT are observable, so could cause side-effects: see for example http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cgroups/freezer-subsystem.txt;h=c21d77742a0799424b09466857681ddcc7100f8b;hb=HEAD#l19 That's correct, but on the other hand some user space processes want to be notified that they're going to be frozen (like NetworkManager, although it probably wants that because of the suspend that's going to happen next). My point here is that being observable need not be a bad thing, depending on the viewpoint. As I understand it, this is really the basis for the modern Android use-case for wakelocks and opportunistic suspend. They prevent non-power-privileged userspace applications from keeping the system from entering a low-power state. (Secondarily, suspend also prevents kernel code from running, e.g., timers set by filesystems, the networking stack, etc.; but problems here should be fixed in the offending kernel code, rather than hacked around, since some of the users of those timers could be important) I think you have oversimplified things a little, but never mind... Well, saying a little is an overstatement. :-) What parts do you feel were oversimplified? In fact, there are several things that wakelocks are being used for, including the one you have mentioned, but also: * Idleness detection (meaning whole system idleness). * Detection of races between system suspend and wakeup events. * Collecting wakeup events statistics (useful for detection of misbehaving applications). The system idleness detection mechanism probably makes the most of the difference between Android and other Linux-based systems PM-wise. This was given as one of the arguments why using the wakelocks mechanism along with the opportunistic suspend might be regarded as a good idea, but I think the _real_ reason why it is used by Android is that the system suspend framework was usable already when Android was being developed and if they wanted to get acceptable battery lives at that time, they simply had no choice but to use it. This is why modern was written in the original text: to contrast with the historical rationale for suspend blockers. As I understand it, in the original Android implementation, the hardware that they were using didn't have fine-grained power management. So system-wide suspend made more sense in that context. But that shouldn't be confused with the modern rationale for wakelocks: https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025668.html On the hardware that shipped we enter the same power state from idle and suspend, so the only power savings we get from suspend that we don't get in idle is from not respecting the scheduler and timers. There is a point in that, because timers wake up the CPU from low-power states entered through CPUuidle. Anyway, I don't quite get your point overall in the ongoing discussion. I'd like to understand it, so we know we're talking about the same things. :-) You seem to be making a point for not supporting system suspend. That may mean two different things, though. First, you may be trying to say that system suspend is a bad idea in general and it shouldn't be supported at all. That I strongly disagree with, because there are platforms where it is the only effective way of saving energy on systems that are not in use, but should become available quickly if necessary. Moreover, there are systems where system suspend makes it possible to save more energy than CPUidle and runtime PM combined. Second, your point may be that for
Re: [linux-pm] Runtime PM discussion notes
On Fri, 24 Jun 2011, Paul Walmsley wrote: But suspend users don't know this either, since they can't predict when the next external wakeup can happen. But they do know (or should know) that they don't intend to use the system in the near future. It might be good to have a separate way to express that idea to the kernel. Are you thinking of the current userspace interfaces to suspend, or something else? I'm not thinking of anything in particular. Just brainstorming... If somebody decides to freeze userspace without putting the entire system to sleep, how will they know when to unfreeze? A certain amount of specialized kernel/userspace interaction would be needed. 1. preventing userspace processes from keeping the system from entering idle 2. preventing userspace processes from waking the system back up It's not clear what this means. How can a user process wake the system up? Are you referring to user timers? Yes. Then those two are almost the same thing. It doesn't seem to make much sense to say I want to stop these processes from running now, but allow them to run if one of them gets a timer or I/O signal. 3. preventing kernel code from keeping the system from entering idle Relatively few kernel threads are freezable. The ones that are tend to be involved in device management. Did you have something specific in mind? No, nothing specific. 4. preventing kernel code from waking the system back up Once userspace is inactive, the kernel probably doesn't have very much to do. Responding to some network packets, maybe, if the network interfaces are left running (like a router but without support for dynamic routing protocols). In general, I don't think a system could do a whole lot of useful work in such a state. 5. requesting that drivers abort what they are currently doing Not exactly abort. More like stop processing their I/O queues. Yes, that's a better way of putting it; hopefully most drivers are doing that. This is more of a transition issue than a steady-state concern. When userspace is frozen, it can't generate new I/O requests. If the old ones were left to terminate normally, pretty soon the I/O queues would drain by themselves. In short, I'm not sure how these ideas would yield anything new and worthwhile. Maybe I'm just slow today... Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Runtime PM discussion notes
Hi Alan, On Thu, 23 Jun 2011, Alan Stern wrote: On Thu, 23 Jun 2011, Paul Walmsley wrote: On Wed, 15 Jun 2011, Rafael J. Wysocki wrote: At the moment, isn't it possible for the userspace ioctl PM interface to freeze processes without going all the way through to a system sleep? Something like cgroup_freezer is probably more useful, since it can freeze a configurable subset of processes. Consider the common mobile use-case of audio playback while the display, touchscreen, etc. are disabled. In such a case, large portions of userspace can be frozen or paused, but not all. But suspend users don't know this either, since they can't predict when the next external wakeup can happen. But they do know (or should know) that they don't intend to use the system in the near future. It might be good to have a separate way to express that idea to the kernel. Are you thinking of the current userspace interfaces to suspend, or something else? and (2) that it is supposed to ignore wakeup signals from certain sources. Isn't this configurable now without system suspend with the wakeup sources code? The wakeup code does two things: It tells the system which devices should be enabled for wakeup when the system sleeps (as opposed to cpuidle, when all devices should be able to generate interrupts), Perhaps the same interface would be useful for CPUIdle-based approaches. The individual components of system suspend are definitely useful: 1. preventing userspace processes from keeping the system from entering idle 2. preventing userspace processes from waking the system back up It's not clear what this means. How can a user process wake the system up? Are you referring to user timers? Yes. 3. preventing kernel code from keeping the system from entering idle Relatively few kernel threads are freezable. The ones that are tend to be involved in device management. Did you have something specific in mind? No, nothing specific. 4. preventing kernel code from waking the system back up 5. requesting that drivers abort what they are currently doing Not exactly abort. More like stop processing their I/O queues. Yes, that's a better way of putting it; hopefully most drivers are doing that. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Runtime PM discussion notes
(Arve cc'ed, also adding Magnus and Kevin back to cc) Hi Rafael, On Thu, 23 Jun 2011, Rafael J. Wysocki wrote: On Thursday, June 23, 2011, Alan Stern wrote: On Thu, 23 Jun 2011, Paul Walmsley wrote: On Wed, 15 Jun 2011, Rafael J. Wysocki wrote: Well, the freezing of user space by itself doesn't buy you anything power management-wise, you pretty much need to do the other things too to really save energy this way. Freezing user space stops CPU-hogging processes from running. When the runqueue is empty, the scheduler can go idle. This in turn allows the CPU(s) to enter low power sleep states via CPUIdle. But you don't have to freeze user space for this purpose, do you? You may simply send a SIGSTOP to those processes. Probably that would be useful for some use-cases. there are two issues with SIGSTOP/SIGCONT that I'm aware of, compared to freezing: 1. if sent from a userspace process, SIGSTOP/SIGCONT are potentially racy with respect to system calls like setsid(), such that the sender may miss some processes; 2. SIGSTOP/SIGCONT are observable, so could cause side-effects: see for example http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cgroups/freezer-subsystem.txt;h=c21d77742a0799424b09466857681ddcc7100f8b;hb=HEAD#l19 As I understand it, this is really the basis for the modern Android use-case for wakelocks and opportunistic suspend. They prevent non-power-privileged userspace applications from keeping the system from entering a low-power state. (Secondarily, suspend also prevents kernel code from running, e.g., timers set by filesystems, the networking stack, etc.; but problems here should be fixed in the offending kernel code, rather than hacked around, since some of the users of those timers could be important) I think you have oversimplified things a little, but never mind... Well, saying a little is an overstatement. :-) What parts do you feel were oversimplified? This was given as one of the arguments why using the wakelocks mechanism along with the opportunistic suspend might be regarded as a good idea, but I think the _real_ reason why it is used by Android is that the system suspend framework was usable already when Android was being developed and if they wanted to get acceptable battery lives at that time, they simply had no choice but to use it. This is why modern was written in the original text: to contrast with the historical rationale for suspend blockers. As I understand it, in the original Android implementation, the hardware that they were using didn't have fine-grained power management. So system-wide suspend made more sense in that context. But that shouldn't be confused with the modern rationale for wakelocks: https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025668.html On the hardware that shipped we enter the same power state from idle and suspend, so the only power savings we get from suspend that we don't get in idle is from not respecting the scheduler and timers. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Runtime PM discussion notes
On Fri, Jun 24, 2011 at 12:53 PM, Paul Walmsley p...@pwsan.com wrote: ... As I understand it, in the original Android implementation, the hardware that they were using didn't have fine-grained power management. So system-wide suspend made more sense in that context. But that shouldn't be confused with the modern rationale for wakelocks: https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025668.html On the hardware that shipped we enter the same power state from idle and suspend, so the only power savings we get from suspend that we don't get in idle is from not respecting the scheduler and timers. This is no longer the case. Both the Nexus-S and Xoom enter lower power states from suspend than idle. -- Arve Hjønnevåg -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Runtime PM discussion notes
2011/6/25 Arve Hjønnevåg a...@android.com: On Fri, Jun 24, 2011 at 12:53 PM, Paul Walmsley p...@pwsan.com wrote: ... As I understand it, in the original Android implementation, the hardware that they were using didn't have fine-grained power management. So system-wide suspend made more sense in that context. But that shouldn't be confused with the modern rationale for wakelocks: https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025668.html On the hardware that shipped we enter the same power state from idle and suspend, so the only power savings we get from suspend that we don't get in idle is from not respecting the scheduler and timers. This is no longer the case. Both the Nexus-S and Xoom enter lower power states from suspend than idle. Interesting, thanks for pointing that out. So this lower-power-state in system suspend, is that a hardware limitation, or just a reflection on effort spent on the CPUIdle portion of the current software implementation? I suspect it's the latter. I've recently been working towards implementing software support for deeper sleep modes on sh7372 in the mainline kernel. With my experimental patch the system suspend case may be able to sleep deeper that current CPUIdle, but that's only because I have not yet tied in enough dependency tracking to make proper decisions from CPUIdle context. Getting sleep modes working transparently with CPUIdle is currently a bit more difficult than simply using system suspend IMO, so I would not be surprised if some vendors simply skip implementing some deeper sleep modes in CPUIdle due to the added complexity. From the hardware perspective nothing is stopping us to use CPUIdle with the lowest sleep states. This is true for all SH-Mobile SoCs including sh7372. Also, we don't rely on firmware for control of the PM states - if anyone is restricted by a firmware interface then obviously it's going to be difficult to do more fine grained power management. Cheers, / magnus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Runtime PM discussion notes
On Thu, 23 Jun 2011, Paul Walmsley wrote: Hi a few thoughts here: On Wed, 15 Jun 2011, Rafael J. Wysocki wrote: On Tuesday, June 14, 2011, Magnus Damm wrote: As for freezing user space, yes, I agree. The other feature including a different set of wakeup sources, not so sure why you would want to have that. I can't think of any good use case for that, from my point of view system-wide suspend is more like the limping cousin of the full-blown kernel. Well, the freezing of user space by itself doesn't buy you anything power management-wise, you pretty much need to do the other things too to really save energy this way. Freezing user space stops CPU-hogging processes from running. When the runqueue is empty, the scheduler can go idle. This in turn allows the CPU(s) to enter low power sleep states via CPUIdle. Very true. At the moment, isn't it possible for the userspace ioctl PM interface to freeze processes without going all the way through to a system sleep? As I understand it, this is really the basis for the modern Android use-case for wakelocks and opportunistic suspend. They prevent non-power-privileged userspace applications from keeping the system from entering a low-power state. (Secondarily, suspend also prevents kernel code from running, e.g., timers set by filesystems, the networking stack, etc.; but problems here should be fixed in the offending kernel code, rather than hacked around, since some of the users of those timers could be important) I think you have oversimplified things a little, but never mind... Anyway, the value of system suspend is to allow the user to tell the system OK, now I'm not going to use you for a while and I don't want the USB mouse to wake you up, so that the system can go into a state in which it draws minimum energy. Of course, you can argue that the system may detect when it's not used and put itself into that state, which is somewhat correct, but the system can _never_ know two things by itself: (1) that it's not going to be used _in_ _advance_ But suspend users don't know this either, since they can't predict when the next external wakeup can happen. But they do know (or should know) that they don't intend to use the system in the near future. It might be good to have a separate way to express that idea to the kernel. Having some kind of indication that the user is done using a device for the time being is definitely useful. But that's separate from system suspend. System suspend is just one of many actions that the system might choose to take when the user gives that indication. Consider something like a screensaver. Usually, the longer latency the wakeup operation is, the longer the screensaver waits before deciding to, say, power the monitor off, or put the system into suspend (as we discussed that Mac OS X does at LinuxCon Boston). Similarly, if there is some background task that really needs to run, an intelligent system will not allow a power economization mode to prevent that from happening. and (2) that it is supposed to ignore wakeup signals from certain sources. Isn't this configurable now without system suspend with the wakeup sources code? The wakeup code does two things: It tells the system which devices should be enabled for wakeup when the system sleeps (as opposed to cpuidle, when all devices should be able to generate interrupts), and it tells the system when a wakeup event has just occurred so that the system won't allow itself to go to sleep before the event can be processed. As I said, support for system suspend allows the user to do more with the system and you really can't implement that functionality differently. You may choose not to implement it at all, but why should you? The individual components of system suspend are definitely useful: 1. preventing userspace processes from keeping the system from entering idle 2. preventing userspace processes from waking the system back up It's not clear what this means. How can a user process wake the system up? Are you referring to user timers? Do we have a way (or want a way) to distinguish between user timers and kernel timers? 3. preventing kernel code from keeping the system from entering idle Relatively few kernel threads are freezable. The ones that are tend to be involved in device management. Did you have something specific in mind? 4. preventing kernel code from waking the system back up 5. requesting that drivers abort what they are currently doing Not exactly abort. More like stop processing their I/O queues. The main issues are that these: 1. are all bundled up into one operation 2. target the entire universe of entities that they manage, rather than selectively targeting non-power-privileged entities That's an interesting way of thinking about it. Thanks for bringing it up. Alan Stern -- To
Re: [linux-pm] Runtime PM discussion notes
Hi, On Thursday, June 23, 2011, Alan Stern wrote: On Thu, 23 Jun 2011, Paul Walmsley wrote: Hi a few thoughts here: On Wed, 15 Jun 2011, Rafael J. Wysocki wrote: On Tuesday, June 14, 2011, Magnus Damm wrote: As for freezing user space, yes, I agree. The other feature including a different set of wakeup sources, not so sure why you would want to have that. I can't think of any good use case for that, from my point of view system-wide suspend is more like the limping cousin of the full-blown kernel. Well, the freezing of user space by itself doesn't buy you anything power management-wise, you pretty much need to do the other things too to really save energy this way. Freezing user space stops CPU-hogging processes from running. When the runqueue is empty, the scheduler can go idle. This in turn allows the CPU(s) to enter low power sleep states via CPUIdle. But you don't have to freeze user space for this purpose, do you? You may simply send a SIGSTOP to those processes. Very true. At the moment, isn't it possible for the userspace ioctl PM interface to freeze processes without going all the way through to a system sleep? Yes, it is. As I understand it, this is really the basis for the modern Android use-case for wakelocks and opportunistic suspend. They prevent non-power-privileged userspace applications from keeping the system from entering a low-power state. (Secondarily, suspend also prevents kernel code from running, e.g., timers set by filesystems, the networking stack, etc.; but problems here should be fixed in the offending kernel code, rather than hacked around, since some of the users of those timers could be important) I think you have oversimplified things a little, but never mind... Well, saying a little is an overstatement. :-) This was given as one of the arguments why using the wakelocks mechanism along with the opportunistic suspend might be regarded as a good idea, but I think the _real_ reason why it is used by Android is that the system suspend framework was usable already when Android was being developed and if they wanted to get acceptable battery lives at that time, they simply had no choice but to use it. Anyway, the value of system suspend is to allow the user to tell the system OK, now I'm not going to use you for a while and I don't want the USB mouse to wake you up, so that the system can go into a state in which it draws minimum energy. Of course, you can argue that the system may detect when it's not used and put itself into that state, which is somewhat correct, but the system can _never_ know two things by itself: (1) that it's not going to be used _in_ _advance_ But suspend users don't know this either, since they can't predict when the next external wakeup can happen. That's going backwards somewhat. First, a suspend user is supposed to choose what devices can wake up the system in response to external events, so he can choose to not allow any devices to do that. Second, if external wakeup sigals (and such that the user doesn't control directly) are enabled, this basically means that the user allows someone else to wake up the system. He may not know when this happens, but that's a bit like saying I don't need you now, but if someone else does, so be it. But they do know (or should know) that they don't intend to use the system in the near future. It might be good to have a separate way to express that idea to the kernel. Starting system suspend means exactly that: Go to a sleep state, because I'm not going to use you now (until I will wake you up). Now, you can set an RTC etc. to wake up the system from sleep states, so people thought it might mean something different, but it simply doesn't. Having some kind of indication that the user is done using a device for the time being is definitely useful. But that's separate from system suspend. System suspend is just one of many actions that the system might choose to take when the user gives that indication. I generally agree, but system should not be confused with the kernel. Let me rephrase what I have already said for many times: system suspend interface in the kernel is for user space, so that it can put the system into a sleep state at any time. The decision to use it need not be made directly by the user, but from the kernel's point of view it doesn't matter. The interface is there and it works how it works. Consider something like a screensaver. Usually, the longer latency the wakeup operation is, the longer the screensaver waits before deciding to, say, power the monitor off, or put the system into suspend (as we discussed that Mac OS X does at LinuxCon Boston). Similarly, if there is some background task that really needs to run, an intelligent system will not allow a power economization mode to prevent that from
