Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
Hi! There are several general problems with the design of opportunistic suspend and suspend-blocks. 1. The opportunistic suspend code bypasses existing Linux kernel code, such as timers and the scheduler, that indicates when code needs to run, and when the system is idle. Whoa! That's not my understanding at all. As I see it, opportunistic suspend doesn't bypass any code that isn't already bypassed by the existing suspend code. Users can do echo mem /sys/power/state whenever they want, without regard to kernel timers and the scheduler (other than the fact that the user's thread must be running in order to carry out the write, of course). Yep. And while I'm co-responsible for that interface, I would not call it exactly nice. Yes, it does the job. But imagine horrors atd/cron would have to do to work properly with that interface... setting rtc wakeups etc. So yes, mem state already breaks promises, but lets not extend that. -- (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] [PATCH 0/8] Suspend block api (version 6)
On Thu 2010-05-13 21:08:14, Matthew Garrett wrote: On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote: The system stays running because there's something to do. The system won't suspend until all the processors hit the kernel idle loop and the next_timer_interrupt_critical() returns nothing. At which point an application in a busy loop cripples you. I think we Application running busy loop already cripples you, with power going from 15W to 50W in thinkpad case. Just avoid badly written apps. -- (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] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 20, 2010 at 07:15:28AM +0200, Florian Mickler wrote: But with that, you still shift the burden of exchanging that app with an feature-equivalent non-broken version to the user. which is not user friendly and not necessary if you have a smart enough kernel. and _without that_, you shift the burden of having a working power management completely into the kernel. Forcing the kernel to deal with completely broken apps. What will happen is that apps developers won't boder thinking about power consumption since the kernel is smart enough to fix their mess. To me that's much bigger burden to the kernel than the other option is to apps. -- balbi -- 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 20, 2010 at 10:57:40AM +0200, ext Felipe Balbi wrote: boder thinking about power consumption since the kernel is smart ^I mean bother -- balbi DefectiveByDesign.org -- 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, 20 May 2010 11:57:40 +0300 Felipe Balbi m...@felipebalbi.com wrote: On Thu, May 20, 2010 at 07:15:28AM +0200, Florian Mickler wrote: But with that, you still shift the burden of exchanging that app with an feature-equivalent non-broken version to the user. which is not user friendly and not necessary if you have a smart enough kernel. and _without that_, you shift the burden of having a working power management completely into the kernel. Forcing the kernel to deal with completely broken apps. What will happen is that apps developers won't boder thinking about power consumption since the kernel is smart enough to fix their mess. To me that's much bigger burden to the kernel than the other option is to apps. You said that already. For me this sounds like you want to take the users hostage in order to get nice (poweraware) apps. Robust system design can take crap and perform well. Users will most of the time prefer a robust system over a nicely designed system. (Just think of the ak-47) I think we just have to agree to disagree here? Cheers, Flo p.s.: don't take me seriously, i'm just a user -- 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] [PATCH 0/8] Suspend block api (version 6)
Hi, On Thu, May 20, 2010 at 12:05:19PM +0200, ext Florian Mickler wrote: You said that already. For me this sounds like you want to take the users hostage in order to get nice (poweraware) apps. not the users, no. The app developers. They should know what bad applications can cause to a nicely done system. Robust system design can take crap and perform well. Users will most of the time prefer a robust system over a nicely designed system. (Just think of the ak-47) (hope you're talking about the gun :-p) put some bad bullets on ak-47 and see if it behaves well, a really crappy trigger will also make it fail. How robust can a system be with badly chosen components ? I think we just have to agree to disagree here? I think so. -- balbi DefectiveByDesign.org -- 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 20, 2010 at 01:27:25PM +0200, ext Vladimir Pantelic wrote: Felipe Balbi wrote: Hi, On Wed, May 19, 2010 at 10:42:55PM +0200, ext Rafael J. Wysocki wrote: Please note that this approach is not too practical for vendors who ship systems like cell phones to the general public. yeah, tell me about it :-p during development on MeeGo devices we try to tackle down as much as possible the use_time offenders and start by filing bugs to those apps, instead of fixing their issues in kernel space. And you will continue doing that once the Meego app store has 100k apps? I'm not here speaking for MeeGo. I'm presenting my own feelings and my own opinion regarding this issue. Don't bring the company into the game, please. -- balbi DefectiveByDesign.org -- 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] [PATCH 0/8] Suspend block api (version 6)
during development on MeeGo devices we try to tackle down as much as possible the use_time offenders and start by filing bugs to those apps, instead of fixing their issues in kernel space. Some apps do abuse kernel mechanisms, and whether the bug is in the app or that kernel mechanism can be a judgement call. I'd expect to see some fixes be appropriately in-kernel; maybe not many though. When reading about this suspend block stuff, does anyone else hear eachoes of APM? It's been ages since that was used, but ISTR it also leveraged handshaking between kernel and userspace. Are there lessons to be applied from there to this discussion? On first principles, I don't see anything wrong with acknowledging that the kernel doesn't have a whole system PM view and thus its PM knowledge could usefully be augmented by information from userspace (applications), possibly on request. Just what that broad PM view consists of gets kind of system-specific. For OMAP hardware, with smart device-level power reduction active almost all the time, it may look different from an ACPI laptop where the BIOS is biased towards saving device power primarily in some suspend state(s) ... or some other hardware platform without much hardware or BIOS assist, where the main PM mechanisms involve software detection/instigation of hardware idleness (and potentially off-ness). And you will continue doing that once the Meego app store has 100k apps? I may have overlooked it, in one of the 100K messsages in my mailbox about versions of suspend block/etc patches ... But surely NOBODY is actually contending that broken aps NOT get fixed?? It's clear to me that tools are needed to identify power hogs; powertop can't be the extent of such tools. (ISTR it doesn't monitor display power usage, for one thing; maybe newer versions do so.) Once such hogs get identified they will need to get fixed. Any other proposal seems broken to me... -- 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 20, 2010 at 10:40:17AM -0700, David Brownell wrote: Some apps do abuse kernel mechanisms, and whether the bug is in the app or that kernel mechanism can be a judgement call. I'd expect to hey come on, there's no judgement call for an app polling every second to check battery status or some other status that doesn't change that frequently. I may have overlooked it, in one of the 100K messsages in my mailbox about versions of suspend block/etc patches ... But surely NOBODY is actually contending that broken aps NOT get fixed?? It's clear to me that tools are needed to identify power hogs; powertop can't be the extent of such tools. (ISTR it doesn't monitor display power usage, for one thing; maybe newer versions do so.) Once such hogs get identified they will need to get fixed. Any other proposal seems broken to me... that's my feeling too. I don't see any needs for suspend blockers in any real system. I acknowledge we need tools probing power consumption to be shipped to production device, that's a good idea, but forcing apps to modify just to have that UI fill up some treeview, I think it's a bit too much. -- balbi -- 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] [PATCH 0/8] Suspend block api (version 6)
-0700, David Brownell wrote: Some apps do abuse kernel mechanisms, and whether the bug is in the app or that kernel mechanism can be a judgement call. I'd expect to hey come on, there's no judgement call for an app polling every second to check battery status or some other status that doesn't change that frequently. Or something as broken as a non-terminating CPU loop ... Of course not. But if there's a kernel mechanism exposed to userspace which really sucks down power ... either it's done correctly and the problem is userspace abusing it, or it's done wrong so that it's not possible to be used correctly. There are some things that just cost power, and that cost can't be escaped. -- 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] [PATCH 0/8] Suspend block api (version 6)
On Tue, May 18, 2010 at 03:59:48PM +0200, ext James Bottomley wrote: On Tue, 2010-05-18 at 09:40 +0300, Felipe Balbi wrote: On Mon, May 17, 2010 at 09:49:35PM +0200, ext James Bottomley wrote: Right, because Firmware writers are from the rugged unresponsive uplands of planet ignore-user-complaints-and-eat-them-for-breakfast-if-they-file-bugs and Software writers are from the emollient responsive groves of planet harmony. Obviously what would work for one wouldn't work for the other. As a software writer, I fully buy into that world view. The trouble is that when I go to dinner with hardware people, they seem to be awfully nice chaps ... almost exactly like me, in fact ... what does this add to suspend_blockers discussion ? Sorry I was evidently being too subtle. The point is that if, as you acknowledge, that you can't train firmware engineers to be responsive, there's no reason to think you can train software engineers in the same quality ... they're very similar people. I wouldn't say it's up to the engineer himself, it's more related to how the company that person works for deal with such things. The corollary is that real world systems have to operate in the face of misbehaving hardware *and* software. I still think the kernel shouldn't deal with broken applications and we shouldn't try to fix them in kernel space. We can, of course, try to find them and have all sorts of bells and whistles shouting 'process %s is preventing CPU from sleeping for %llu nanoseconds' or something like that. -- balbi DefectiveByDesign.org -- 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] [PATCH 0/8] Suspend block api (version 6)
On Wednesday 19 May 2010, Felipe Balbi wrote: On Tue, May 18, 2010 at 03:59:48PM +0200, ext James Bottomley wrote: On Tue, 2010-05-18 at 09:40 +0300, Felipe Balbi wrote: On Mon, May 17, 2010 at 09:49:35PM +0200, ext James Bottomley wrote: Right, because Firmware writers are from the rugged unresponsive uplands of planet ignore-user-complaints-and-eat-them-for-breakfast-if-they-file-bugs and Software writers are from the emollient responsive groves of planet harmony. Obviously what would work for one wouldn't work for the other. As a software writer, I fully buy into that world view. The trouble is that when I go to dinner with hardware people, they seem to be awfully nice chaps ... almost exactly like me, in fact ... what does this add to suspend_blockers discussion ? Sorry I was evidently being too subtle. The point is that if, as you acknowledge, that you can't train firmware engineers to be responsive, there's no reason to think you can train software engineers in the same quality ... they're very similar people. I wouldn't say it's up to the engineer himself, it's more related to how the company that person works for deal with such things. The corollary is that real world systems have to operate in the face of misbehaving hardware *and* software. I still think the kernel shouldn't deal with broken applications and we shouldn't try to fix them in kernel space. We can, of course, try to find them and have all sorts of bells and whistles shouting 'process %s is preventing CPU from sleeping for %llu nanoseconds' or something like that. Please note that this approach is not too practical for vendors who ship systems like cell phones to the general public. 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] [PATCH 0/8] Suspend block api (version 6)
On Wed, 19 May 2010 09:59:34 +0300 Felipe Balbi felipe.ba...@nokia.com wrote: The corollary is that real world systems have to operate in the face of misbehaving hardware *and* software. I still think the kernel shouldn't deal with broken applications and we shouldn't try to fix them in kernel space. We can, of course, try to find them and have all sorts of bells and whistles shouting 'process %s is preventing CPU from sleeping for %llu nanoseconds' or something like that. But with that, you still shift the burden of exchanging that app with an feature-equivalent non-broken version to the user. which is not user friendly and not necessary if you have a smart enough kernel. Cheers, Flo -- 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] [PATCH 0/8] Suspend block api (version 6)
On Mon, May 17, 2010 at 09:49:35PM +0200, ext James Bottomley wrote: Right, because Firmware writers are from the rugged unresponsive uplands of planet ignore-user-complaints-and-eat-them-for-breakfast-if-they-file-bugs and Software writers are from the emollient responsive groves of planet harmony. Obviously what would work for one wouldn't work for the other. As a software writer, I fully buy into that world view. The trouble is that when I go to dinner with hardware people, they seem to be awfully nice chaps ... almost exactly like me, in fact ... what does this add to suspend_blockers discussion ? -- balbi DefectiveByDesign.org -- 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] [PATCH 0/8] Suspend block api (version 6)
Alan Stern st...@rowland.harvard.edu writes: On Fri, 14 May 2010, Brian Swetland wrote: In tickless mode, the time until next timer is a signed int, so the longest the kernel will ever sleep is ~2 seconds at a go. In practice, userspace entities often have polling behavior that can trigger more often than that, and I've observed some kernel periodic timers (haven't cataloged them recently) that happen more often than once a second. Paul and Kevin, how does the OMAP implementation handle these difficulties? just a minor clarification... these aren't OMAP-specific issues, but generic issues to all power-sensitive kernel users. The ~2 second limit was fixed by Jon Hunter (TI) and is in mainline since 2.6.32[1]. For other timers, there has been active work (mostly by Intel folks) on deferrable timers, coalescing timers, timer slack etc. that has greatly reduced the kernel timer impact on wakeups. Also, how does it handle the issue of ill-behaved apps? For userspace, apps that have polling behavior or are ill-behaved must be found and fixed. Thanks to tools like powertop, this is a farily easy task. But really, I don't consider the ill-behaved app problem to be a real-world problem. Both in maemo/meego and Android, if someone writes an app that kills battery life, it will get reported as a bug, or get bad ratings etc. On these kinds of devices, there is a *stong* developer incentive to not write battery sucking apps. Kevin [1] commit 97813f2fe77804a4464564c75ba8d8826377feea Author: Jon Hunter jon-hun...@ti.com Date: Tue Aug 18 12:45:11 2009 -0500 nohz: Allow 32-bit machines to sleep for more than 2.15 seconds In the dynamic tick code, max_delta_ns (member of the clock_event_device structure) represents the maximum sleep time that can occur between timer events in nanoseconds. The variable, max_delta_ns, is defined as an unsigned long which is a 32-bit integer for 32-bit machines and a 64-bit integer for 64-bit machines (if -m64 option is used for gcc). The value of max_delta_ns is set by calling the function clockevent_delta2ns() which returns a maximum value of LONG_MAX. For a 32-bit machine LONG_MAX is equal to 0x7fff and in nanoseconds this equates to ~2.15 seconds. Hence, the maximum sleep time for a 32-bit machine is ~2.15 seconds, where as for a 64-bit machine it will be many years. This patch changes the type of max_delta_ns to be u64 instead of unsigned long so that this variable is a 64-bit type for both 32-bit and 64-bit machines. It also changes the maximum value returned by clockevent_delta2ns() to KTIME_MAX. Hence this allows a 32-bit machine to sleep for longer than ~2.15 seconds. Please note that this patch also changes min_delta_ns to be u64 too and although this is unnecessary, it makes the patch simpler as it avoids to fixup all callers of clockevent_delta2ns(). [ tglx: changed unsigned long long to u64 as we use this data type through out the time code ] Signed-off-by: Jon Hunter jon-hun...@ti.com Cc: John Stultz johns...@us.ibm.com LKML-Reference: 1250617512-23567-3-git-send-email-jon-hun...@ti.com Signed-off-by: Thomas Gleixner t...@linutronix.de -- 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] [PATCH 0/8] Suspend block api (version 6)
On Mon, 2010-05-17 at 08:40 -0700, Kevin Hilman wrote: Also, how does it handle the issue of ill-behaved apps? For userspace, apps that have polling behavior or are ill-behaved must be found and fixed. Thanks to tools like powertop, this is a farily easy task. That's a bit glib ... powertop can detect power consumption stats on a running system ... if you have a polling app preventing your system from suspending, powertop isn't necessarily going to find it ... especially if the polling interval is of the order of powertop's. Powertop can find the bad tens of wakeups per second, but it only takes one wakup every few seconds or so to drain the battery significantly when operating on suspend from idle. But really, I don't consider the ill-behaved app problem to be a real-world problem. Both in maemo/meego and Android, if someone writes an app that kills battery life, it will get reported as a bug, or get bad ratings etc. On these kinds of devices, there is a *stong* developer incentive to not write battery sucking apps. I'm not sure this is real world, either. Developers can fire up powertop from the command line when their phone isn't idling for as long as it should. But a phone is a consumer device: the average smart phone user just wants to browse the web, get email, go to facebook and play with some cool apps. If one of those cool apps is rogue, they're not really going to know which one or how to find it (and firing up powertop from the command line isn't something which will occur to them as a matter of routine). One of the nice things that suspend blockers actually does is to give the kernel a clear name for the process blocking suspend (and thus consuming power). This allows a nice way to assign power budget to the application and present who's using what in a nice visible form, which does facilitate the reporting of bad apps, even for the non-developer user. James -- 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] [PATCH 0/8] Suspend block api (version 6)
On Mon, May 17, 2010 at 01:04:45PM -0400, James Bottomley wrote: For userspace, apps that have polling behavior or are ill-behaved must be found and fixed. Thanks to tools like powertop, this is a farily easy task. That's a bit glib ... powertop can detect power consumption stats on a running system ... if you have a polling app preventing your system from suspending, powertop isn't necessarily going to find it ... especially if the polling interval is of the order of powertop's. Powertop can find the bad tens of wakeups per second, but it only takes one wakup every few seconds or so to drain the battery significantly when operating on suspend from idle. you can always increase powertop's interval through command line and once you went down to 1 wakeup every two seconds, you increase powertop's interval and try to cut down 10 more ill-behaved apps. And you keep going until you have e.g. 1 wakeup per minute or whatever your target is. But really, I don't consider the ill-behaved app problem to be a real-world problem. Both in maemo/meego and Android, if someone writes an app that kills battery life, it will get reported as a bug, or get bad ratings etc. On these kinds of devices, there is a *stong* developer incentive to not write battery sucking apps. I'm not sure this is real world, either. Developers can fire up powertop from the command line when their phone isn't idling for as long as it should. But a phone is a consumer device: the average smart phone user just wants to browse the web, get email, go to facebook and play with some cool apps. If one of those cool apps is rogue, they're not really going to know which one or how to find it (and firing up powertop from the command line isn't something which will occur to them as a matter of routine). Agree with you here. One of the nice things that suspend blockers actually does is to give the kernel a clear name for the process blocking suspend (and thus consuming power). This allows a nice way to assign power budget to the application and present who's using what in a nice visible form, which does facilitate the reporting of bad apps, even for the non-developer user. if that's the only thing we want suspend_blockers for, there are other simpler ways to do it. Just add a kernel debugging option for anyone doing poll() or keeping a device open() or whatever and you have the name the of the processes consuming power and preventing system from going into sleep. IMO, suspend_blocker is trying to fix application problems in kernel space by unconditionaly (well sort of) freezing userspace if there are no suspen_blockers held. So even if application is doing poll(pfds, ARRAY_SIZE(pfds), 2); that won't be noticed because as long as the suspend_blocker is released, that poll() will be frozen, no ? IMO the real fix would be on that particular poll(), changing the timeout e.g. based on cpufreq notifications or even relying completely on IRQs with poll(pdfs, ARRAY_SIZE(pfds), -1); Of course, this is only a crude example trying to show that the real issue lies on the application rather than on kernel. -- balbi -- 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] [PATCH 0/8] Suspend block api (version 6)
On Mon, May 17, 2010 at 08:47:31PM +0300, Felipe Balbi wrote: IMO the real fix would be on that particular poll(), changing the timeout e.g. based on cpufreq notifications or even relying completely on IRQs with poll(pdfs, ARRAY_SIZE(pfds), -1); Of course, this is only a crude example trying to show that the real issue lies on the application rather than on kernel. We know that this problem is mostly uninteresting if your userland is well written. The sad truth is that it's impossible to trust that your userland is well written, and broadly impossible to communicate to users that the reason that their battery life is miserable is because of the applications and not because of the platform. If you don't believe that that's a worthwhile use case to deal with then suspend blockers buy you pretty much nothing. But if you do, then nobody's yet demonstrated another workable way for this to be handled. -- Matthew Garrett | mj...@srcf.ucam.org -- 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] [PATCH 0/8] Suspend block api (version 6)
On Mon, 2010-05-17 at 20:47 +0300, Felipe Balbi wrote: On Mon, May 17, 2010 at 01:04:45PM -0400, James Bottomley wrote: For userspace, apps that have polling behavior or are ill-behaved must be found and fixed. Thanks to tools like powertop, this is a farily easy task. That's a bit glib ... powertop can detect power consumption stats on a running system ... if you have a polling app preventing your system from suspending, powertop isn't necessarily going to find it ... especially if the polling interval is of the order of powertop's. Powertop can find the bad tens of wakeups per second, but it only takes one wakup every few seconds or so to drain the battery significantly when operating on suspend from idle. you can always increase powertop's interval through command line and once you went down to 1 wakeup every two seconds, you increase powertop's interval and try to cut down 10 more ill-behaved apps. And you keep going until you have e.g. 1 wakeup per minute or whatever your target is. Have you actually tried this? On my N1 with CM5.0.6 just running powertop requires me to keep the USB system up (debugging cable) and paths into the usb console ... all of this produces significant wakeup distortion, mostly in the msm i2c subsystem. But in all the noise it's hard to find rogue applications. But really, I don't consider the ill-behaved app problem to be a real-world problem. Both in maemo/meego and Android, if someone writes an app that kills battery life, it will get reported as a bug, or get bad ratings etc. On these kinds of devices, there is a *stong* developer incentive to not write battery sucking apps. I'm not sure this is real world, either. Developers can fire up powertop from the command line when their phone isn't idling for as long as it should. But a phone is a consumer device: the average smart phone user just wants to browse the web, get email, go to facebook and play with some cool apps. If one of those cool apps is rogue, they're not really going to know which one or how to find it (and firing up powertop from the command line isn't something which will occur to them as a matter of routine). Agree with you here. One of the nice things that suspend blockers actually does is to give the kernel a clear name for the process blocking suspend (and thus consuming power). This allows a nice way to assign power budget to the application and present who's using what in a nice visible form, which does facilitate the reporting of bad apps, even for the non-developer user. if that's the only thing we want suspend_blockers for, there are other simpler ways to do it. Nice straw man slide. The technical reason for wanting suspend blockers (as has been stated more times than I can be bothered to go back and count) is that no-one can currently produce a working model for race free kernel to user work handoff and, in the face of open app stores, rogue applications are a significant problem. The fact that suspend blockers enables easy identification of power hogging apps is just a very useful side effect. James Just add a kernel debugging option for anyone doing poll() or keeping a device open() or whatever and you have the name the of the processes consuming power and preventing system from going into sleep. IMO, suspend_blocker is trying to fix application problems in kernel space by unconditionaly (well sort of) freezing userspace if there are no suspen_blockers held. So even if application is doing poll(pfds, ARRAY_SIZE(pfds), 2); that won't be noticed because as long as the suspend_blocker is released, that poll() will be frozen, no ? IMO the real fix would be on that particular poll(), changing the timeout e.g. based on cpufreq notifications or even relying completely on IRQs with poll(pdfs, ARRAY_SIZE(pfds), -1); Of course, this is only a crude example trying to show that the real issue lies on the application rather than on kernel. -- 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] [PATCH 0/8] Suspend block api (version 6)
Hi, On Mon, May 17, 2010 at 01:59:39PM -0400, James Bottomley wrote: Have you actually tried this? On my N1 with CM5.0.6 just running powertop requires me to keep the USB system up (debugging cable) and paths into the usb console ... all of this produces significant wakeup distortion, mostly in the msm i2c subsystem. But in all the noise it's hard to find rogue applications. Well, I use serial console, but in the worst case scenario I would make powertop save the output to a memory buffer a big one, and after finished flush to some mmc or anything like that. The technical reason for wanting suspend blockers (as has been stated more times than I can be bothered to go back and count) is that no-one can currently produce a working model for race free kernel to user work handoff and, in the face of open app stores, rogue applications are a significant problem. The fact that suspend blockers enables easy identification of power hogging apps is just a very useful side effect. I still can't get over the fact that suspend_blockers are dealing with userland problems in kernel space. If we can't really trust apps, I'm sorry but companies like Google and Nokia (which I work for) will have to setup better application acceptance on their stores. The fact that we can get statistics of power usage from kernel space is actually really good and could be easily automated on an AppStore environment. If it's cause too many wakeups you report that to the developer of the app before accepting. The same feature could be shipped on the SDK, so developer has also early feedback about how good (or bad) his/her application really is to the system. IMO we should be celebrating good apps, not dealing in kernel space with bad ones. And on top of all that, we would still need custom applications with suspend_blockers support built into them. -- balbi -- 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] [PATCH 0/8] Suspend block api (version 6)
On Mon, May 17, 2010 at 11:12 AM, Felipe Balbi m...@felipebalbi.com wrote: The technical reason for wanting suspend blockers (as has been stated more times than I can be bothered to go back and count) is that no-one can currently produce a working model for race free kernel to user work handoff and, in the face of open app stores, rogue applications are a significant problem. The fact that suspend blockers enables easy identification of power hogging apps is just a very useful side effect. I still can't get over the fact that suspend_blockers are dealing with userland problems in kernel space. If we can't really trust apps, I'm sorry but companies like Google and Nokia (which I work for) will have to setup better application acceptance on their stores. We (Google) would like to allow completely open app distribution with minimal hurdles, and avoid the walled garden approach. Toward this goal we're not even requiring the use of a central app store for distribution. Obviously, given the ability to run *any* app, users will run into bad (or perhaps just less-than-optimal-powerwise) apps. Being able to provide the best possible battery life (in spite of sometimes-nonoptimal userspace apps) and simultaneously informing users about which apps are better/worse for their battery life is a goal here. IMO we should be celebrating good apps, not dealing in kernel space with bad ones. And on top of all that, we would still need custom applications with suspend_blockers support built into them. For a large majority of apps, running in the background while the device is asleep (screen off) is not essential, they don't request the keep device awake permission, never hold a wakelock, etc. Those that do need to do this have the permission, may hold suspend blockers, and are accounted for. Unrelated to apps, the ability to say please enter suspend as soon as there's no more work (kernel or userspace) preventing it, in a simple, non-racy way is useful. Brian -- 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] [PATCH 0/8] Suspend block api (version 6)
Hi, On Mon, May 17, 2010 at 11:26:59AM -0700, Brian Swetland wrote: We (Google) would like to allow completely open app distribution with minimal hurdles, and avoid the walled garden approach. Toward this goal we're not even requiring the use of a central app store for distribution. I understand that, but still we should be telling developers what they're doing wrong so that they can improve themselves as professionals and still make the final device better. Obviously, given the ability to run *any* app, users will run into bad (or perhaps just less-than-optimal-powerwise) apps. Being able to provide the best possible battery life (in spite of sometimes-nonoptimal userspace apps) and simultaneously informing users about which apps are better/worse for their battery life is a goal here. I see. Just hope MeeGo doesn't venture on the same waters :-s For a large majority of apps, running in the background while the device is asleep (screen off) is not essential, they don't request the keep device awake permission, never hold a wakelock, etc. Those that do need to do this have the permission, may hold suspend blockers, and are accounted for. but can anyone write an app that holds a suspend_blocker ?? If so, then your goal is already broken, right ? I mean, if anyone can keep a suspend_blocker held forever, you'll never ever sleep, right ? While with runtime, if you keep the keypad open, only the keypad and the paths directly related to it (probably the i2c controller and the power domain where the i2c controller sits) will be kept alive, no ? Unrelated to apps, the ability to say please enter suspend as soon as there's no more work (kernel or userspace) preventing it, in a simple, non-racy way is useful. I just tend to agree with Kevin on questioning how different how different this actually is from runtime_pm. I guess I would need to dig through some documentation in order to understand but it seems really similar. -- balbi -- 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] [PATCH 0/8] Suspend block api (version 6)
On Mon, May 17, 2010 at 11:39 AM, Felipe Balbi m...@felipebalbi.com wrote: Hi, On Mon, May 17, 2010 at 11:26:59AM -0700, Brian Swetland wrote: We (Google) would like to allow completely open app distribution with minimal hurdles, and avoid the walled garden approach. Toward this goal we're not even requiring the use of a central app store for distribution. I understand that, but still we should be telling developers what they're doing wrong so that they can improve themselves as professionals and still make the final device better. I agree. Which is why we develop tools to help developers understand what their apps are doing. For a large majority of apps, running in the background while the device is asleep (screen off) is not essential, they don't request the keep device awake permission, never hold a wakelock, etc. Those that do need to do this have the permission, may hold suspend blockers, and are accounted for. but can anyone write an app that holds a suspend_blocker ?? If so, then your goal is already broken, right ? I mean, if anyone can keep a suspend_blocker held forever, you'll never ever sleep, right ? While with runtime, if you keep the keypad open, only the keypad and the paths directly related to it (probably the i2c controller and the power domain where the i2c controller sits) will be kept alive, no ? No, you'll never suspend, which is different from never going to the lowest CPU power state. On shipping Android devices we aggressively completely power down the CPU in idle whenever we can (based on latency requirements generally). We power off peripherals whenever they're not in use. This is why I've stated previously that I don't think runtime PM and opportunistic suspend are competitive features. Everyone who cares about minimizing power should want runtime pm or at least similar functionality (our drivers have always powered down peripherals when not in use, even while the device is open, etc, prior to the existence of runtime PM). If your environment is such that going to full suspend will not gain you anything, then don't use opportunistic suspend. We find that there are savings to be had with this model in Android which is why we use it. If you are going to use opportunistic suspend, suspend_blockers provide useful functionality. Brian -- 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] [PATCH 0/8] Suspend block api (version 6)
On Mon, May 17, 2010 at 09:39:05PM +0300, Felipe Balbi wrote: On Mon, May 17, 2010 at 11:26:59AM -0700, Brian Swetland wrote: For a large majority of apps, running in the background while the device is asleep (screen off) is not essential, they don't request the keep device awake permission, never hold a wakelock, etc. Those that do need to do this have the permission, may hold suspend blockers, and are accounted for. but can anyone write an app that holds a suspend_blocker ?? If so, then your goal is already broken, right ? I mean, if anyone can keep a suspend_blocker held forever, you'll never ever sleep, right ? While with runtime, if you keep the keypad open, only the keypad and the paths directly related to it (probably the i2c controller and the power domain where the i2c controller sits) will be kept alive, no ? The Android UI provides a list of which applications have been preventing suspend and how long for, the idea being that if something has been holding suspend blockers for ever you can at least look at the list and see what it was. -- 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] [PATCH 0/8] Suspend block api (version 6)
On Mon, May 17, 2010 at 11:39 AM, Felipe Balbi m...@felipebalbi.com wrote: Hi, On Mon, May 17, 2010 at 11:26:59AM -0700, Brian Swetland wrote: We (Google) would like to allow completely open app distribution with minimal hurdles, and avoid the walled garden approach. Toward this goal we're not even requiring the use of a central app store for distribution. I understand that, but still we should be telling developers what they're doing wrong so that they can improve themselves as professionals and still make the final device better. We currently do track power usage per-application which is displayed in the phone UI. (Settings - About Phone - Battery Usage). We also provide several (although not perfect) command line utilities for developers to see their power impact system. We are constantly working on ways to improve tracking and make such power data more accessible to developers so they can see how their applications are impacting battery life. Obviously, given the ability to run *any* app, users will run into bad (or perhaps just less-than-optimal-powerwise) apps. Being able to provide the best possible battery life (in spite of sometimes-nonoptimal userspace apps) and simultaneously informing users about which apps are better/worse for their battery life is a goal here. I see. Just hope MeeGo doesn't venture on the same waters :-s For a large majority of apps, running in the background while the device is asleep (screen off) is not essential, they don't request the keep device awake permission, never hold a wakelock, etc. Those that do need to do this have the permission, may hold suspend blockers, and are accounted for. but can anyone write an app that holds a suspend_blocker ?? If so, then your goal is already broken, right ? I mean, if anyone can keep a suspend_blocker held forever, you'll never ever sleep, right ? While with runtime, if you keep the keypad open, only the keypad and the paths directly related to it (probably the i2c controller and the power domain where the i2c controller sits) will be kept alive, no ? Any app can grab a suspend blocker, and the stats are logged, and if you're app is abusing wakelocks and CPU resource it will show up in the Battery Use panel. -- Mike Unrelated to apps, the ability to say please enter suspend as soon as there's no more work (kernel or userspace) preventing it, in a simple, non-racy way is useful. I just tend to agree with Kevin on questioning how different how different this actually is from runtime_pm. I guess I would need to dig through some documentation in order to understand but it seems really similar. -- balbi -- 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 -- 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] [PATCH 0/8] Suspend block api (version 6)
James Bottomley james.bottom...@suse.de writes: The technical reason for wanting suspend blockers (as has been stated more times than I can be bothered to go back and count) is that no-one can currently produce a working model for race free kernel to user work handoff At least I've never heard this technial reason stated so succinctly. It's not in the changelogs or in the Documentation file included. The way I undertand things, today's mainline kernel has a race-free kernel-to-user work handoff already. The possibility of races is introduced by the opportunistic suspend feature itself (patch 1.) The use of suspend blockers later in the series is needed to avoid the potential races introduced by opportunistic suspend. Kevin -- 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] [PATCH 0/8] Suspend block api (version 6)
On Mon, 2010-05-17 at 21:12 +0300, Felipe Balbi wrote: Hi, On Mon, May 17, 2010 at 01:59:39PM -0400, James Bottomley wrote: Have you actually tried this? On my N1 with CM5.0.6 just running powertop requires me to keep the USB system up (debugging cable) and paths into the usb console ... all of this produces significant wakeup distortion, mostly in the msm i2c subsystem. But in all the noise it's hard to find rogue applications. Well, I use serial console, but in the worst case scenario I would make powertop save the output to a memory buffer a big one, and after finished flush to some mmc or anything like that. Surely, depending on your UART FIFO depth, of course, a serial console interrupts once every 16 characters or so ... how do you filter out that storm of interrupts refreshing the powertop screen from the actual application problems? But anyway, the average user probably either doesn't have or doesn't know how to get to a serial console on their phone ... The technical reason for wanting suspend blockers (as has been stated more times than I can be bothered to go back and count) is that no-one can currently produce a working model for race free kernel to user work handoff and, in the face of open app stores, rogue applications are a significant problem. The fact that suspend blockers enables easy identification of power hogging apps is just a very useful side effect. I still can't get over the fact that suspend_blockers are dealing with userland problems in kernel space. If we can't really trust apps, I'm sorry but companies like Google and Nokia (which I work for) will have to setup better application acceptance on their stores. The fact that we can get statistics of power usage from kernel space is actually really good and could be easily automated on an AppStore environment. If it's cause too many wakeups you report that to the developer of the app before accepting. The same feature could be shipped on the SDK, so developer has also early feedback about how good (or bad) his/her application really is to the system. IMO we should be celebrating good apps, not dealing in kernel space with bad ones. And on top of all that, we would still need custom applications with suspend_blockers support built into them. If you actually s/app/USB storage device/ (with a few other obvious text changes) in most of the above two paragraphs, you've got a good description of the problems we go through on an almost daily basis in the kernel for USB storage ... and why we've grown a massive exception table. Just saying devices should conform to specifications is a wonderful magic wand for wishing away all the problems bad devices cause and bludgeoning manufacturers with the said spec wrapped around a large lead brick is very cathartic but it doesn't change the fact that users blame the kernel for not working with the bad devices ... and we gave up trying to re-educate users on that score years ago. James -- 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] [PATCH 0/8] Suspend block api (version 6)
Hi, On Mon, May 17, 2010 at 03:24:27PM -0400, James Bottomley wrote: Surely, depending on your UART FIFO depth, of course, a serial console interrupts once every 16 characters or so ... how do you filter out that storm of interrupts refreshing the powertop screen from the actual application problems? But anyway, the average user probably either doesn't have or doesn't know how to get to a serial console on their phone ... like I said: use a big memory buffer and print to that. Only flush after you're done profiling. Something like dmesg. If you actually s/app/USB storage device/ (with a few other obvious text changes) in most of the above two paragraphs, you've got a good description of the problems we go through on an almost daily basis in the kernel for USB storage ... and why we've grown a massive exception table. Just saying devices should conform to specifications is a wonderful magic wand for wishing away all the problems bad devices cause and bludgeoning manufacturers with the said spec wrapped around a large lead brick is very cathartic but it doesn't change the fact that users blame the kernel for not working with the bad devices ... and we gave up trying to re-educate users on that score years ago. that's a whole other story. Hardware issues are things which in 99.999% of the cases we can't change. We have to work around them. Software bugs, on the other hand, can be fixed much more easily. I'm sure you agree with that, don't you ? Trying to make a comparisson between hardware bug and software bug is simply non-sense in this case. -- balbi -- 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] [PATCH 0/8] Suspend block api (version 6)
hi, On Mon, May 17, 2010 at 10:38:40PM +0300, Felipe Balbi wrote: that's a whole other story. Hardware issues are things which in 99.999% of the cases we can't change. We have to work around them. Software bugs, on the other hand, can be fixed much more easily. I'm sure you agree with that, don't you ? Trying to make a comparisson between hardware bug and software bug is simply non-sense in this case. before you reply saying that most of the problems are firmware bugs, try to file a bug to any of the usb storage manufacturers and wait for them to fix. It's virtualy impossible, so let's consider it a problem that has to be worked around. -- balbi -- 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] [PATCH 0/8] Suspend block api (version 6)
On Mon, 2010-05-17 at 22:39 +0300, Felipe Balbi wrote: hi, On Mon, May 17, 2010 at 10:38:40PM +0300, Felipe Balbi wrote: that's a whole other story. Hardware issues are things which in 99.999% of the cases we can't change. We have to work around them. Software bugs, on the other hand, can be fixed much more easily. I'm sure you agree with that, don't you ? Trying to make a comparisson between hardware bug and software bug is simply non-sense in this case. before you reply saying that most of the problems are firmware bugs, try to file a bug to any of the usb storage manufacturers and wait for them to fix. It's virtualy impossible, so let's consider it a problem that has to be worked around. Right, because Firmware writers are from the rugged unresponsive uplands of planet ignore-user-complaints-and-eat-them-for-breakfast-if-they-file-bugs and Software writers are from the emollient responsive groves of planet harmony. Obviously what would work for one wouldn't work for the other. As a software writer, I fully buy into that world view. The trouble is that when I go to dinner with hardware people, they seem to be awfully nice chaps ... almost exactly like me, in fact ... James -- 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] [PATCH 0/8] Suspend block api (version 6)
On Mon, May 17, 2010 at 12:27 PM, Vitaly Wool vitalyw...@gmail.com wrote: On Mon, May 17, 2010 at 6:12 PM, Kevin Hilman khil...@deeprootsystems.com wrote: and #2, the battery lifetime on the N770 and N800 (both of which I have) is **appalling** **bad**. Appalling bad compared to what? What's probably more interesting in terms of rough comparisons is comparing similar devices with and without opportunistic suspend. The Nokia n900 (maemo) and the Moto Droid (android) use the same SoC (TI OMAP3) and roughly the same kernel (2.6.2[89], although both are heavily patched from mainline.) The n900 *never* suspends. It only uses dynamic PM + CPUidle. The droid uses opportunistic suspend (as well as dynamic PM + CPUidle) I don't know of any more objective comparison of the two, but as a user of both devices I can say that the active usage is basically the same (around a day) and the idle use is similar as well, even though the Droid has a slightly bigger battery (1400 mAh vs. 1320 mAh.) My own usage suggests the n900 is a bit better in idle time, but I have not done any measuring or objective tests. I'm guessing the difference is probably because the Droid does not use the deepest off-mode power states either in idle or suspend (IIRC) where the n900 does. I suspect that if both were using off-mode and had the same battery, these differences would go away. Although both are OMAP3430 and run 2.6.29 you cannot compare the N900 and Droid's perceived user battery life to one another to evaluate opportunistic suspend. There are many factors uncounted for such as: network reception, screen brightness (and size), button back-light, keyboard back-light, modem stack (CDMA vs UMTS). Also the difference in uerspace. While this is not really a scientific comparison, it at least gives a rough idea. If using opportunistic suspend was adding noticably better battery life, I think this would be a different discussion. Exactly. The point is, opportunistic suspend doesn't in fact add any value compared to dynamic PM + CPUIdle. It only produces some false impression that one can handle power management right without using dynamic PM. And this false impression is the cause for many really ugly designs (like, for instance, 15 minutes touchscreen inactivity delay before forcibly shutting down the wireless, as it's done in stock Android framework). Opportunistic suspend is an extension to the current suspend model, not a replacement dynamic / run-time PM. If you can replace good old suspend then this would be a different story. As you mention, Droid uses opportunistic suspend + dynamic pm + cpuidle + freq. So I decided to do some measurements on a Droid using our 2.9.32 kernel (http://android.git.kernel.org/?p=kernel/omap.git;a=summary). For a little better apples to apples comparison. Droid (idle system, airplane mode, screen off, 3 min interval): measured average current - with opportunity suspend: 3.19mA - without opportunistic suspend: 3.5mA Stock userspace build, all I did was replace the kernel. We are hitting retention on idle as well as suspend for omap (instead of full off-mode). Also, your point about wifi, the 15 min timeout is in the framework and is configurable in the code and via UI, nothing to do with kernel, opportunistic suspend or run time suspend. -- Mike Thanks, Vitaly ___ linux-pm mailing list linux...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/linux-pm -- 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] [PATCH 0/8] Suspend block api (version 6)
On Mon, May 17, 2010 at 10:07 PM, Mike Chan m...@android.com wrote: On Mon, May 17, 2010 at 12:27 PM, Vitaly Wool vitalyw...@gmail.com wrote: On Mon, May 17, 2010 at 6:12 PM, Kevin Hilman khil...@deeprootsystems.com wrote: and #2, the battery lifetime on the N770 and N800 (both of which I have) is **appalling** **bad**. Appalling bad compared to what? What's probably more interesting in terms of rough comparisons is comparing similar devices with and without opportunistic suspend. The Nokia n900 (maemo) and the Moto Droid (android) use the same SoC (TI OMAP3) and roughly the same kernel (2.6.2[89], although both are heavily patched from mainline.) The n900 *never* suspends. It only uses dynamic PM + CPUidle. The droid uses opportunistic suspend (as well as dynamic PM + CPUidle) I don't know of any more objective comparison of the two, but as a user of both devices I can say that the active usage is basically the same (around a day) and the idle use is similar as well, even though the Droid has a slightly bigger battery (1400 mAh vs. 1320 mAh.) My own usage suggests the n900 is a bit better in idle time, but I have not done any measuring or objective tests. I'm guessing the difference is probably because the Droid does not use the deepest off-mode power states either in idle or suspend (IIRC) where the n900 does. I suspect that if both were using off-mode and had the same battery, these differences would go away. Although both are OMAP3430 and run 2.6.29 you cannot compare the N900 and Droid's perceived user battery life to one another to evaluate opportunistic suspend. There are many factors uncounted for such as: network reception, screen brightness (and size), button back-light, keyboard back-light, modem stack (CDMA vs UMTS). Also the difference in uerspace. While this is not really a scientific comparison, it at least gives a rough idea. If using opportunistic suspend was adding noticably better battery life, I think this would be a different discussion. Exactly. The point is, opportunistic suspend doesn't in fact add any value compared to dynamic PM + CPUIdle. It only produces some false impression that one can handle power management right without using dynamic PM. And this false impression is the cause for many really ugly designs (like, for instance, 15 minutes touchscreen inactivity delay before forcibly shutting down the wireless, as it's done in stock Android framework). Opportunistic suspend is an extension to the current suspend model, not a replacement dynamic / run-time PM. If you can replace good old suspend then this would be a different story. Yes, but what does it extend? What aspect it makes the current suspend model better in? As you mention, Droid uses opportunistic suspend + dynamic pm + cpuidle + freq. So I decided to do some measurements on a Droid using our 2.9.32 kernel (http://android.git.kernel.org/?p=kernel/omap.git;a=summary). For a little better apples to apples comparison. Droid (idle system, airplane mode, screen off, 3 min interval): measured average current - with opportunity suspend: 3.19mA - without opportunistic suspend: 3.5mA Stock userspace build, all I did was replace the kernel. We are hitting retention on idle as well as suspend for omap (instead of full off-mode). That's implementation specific. If CPUIdle implemented CPU deep sleep, I bet you would see different figures. Also, your point about wifi, the 15 min timeout is in the framework and is configurable in the code and via UI, nothing to do with kernel, opportunistic suspend or run time suspend. You don't quite get it :) This should NOT at all be timeout driven. This should be activity driven or constraint driven which perfectly fits into the runtime PM paradigm but is in no way cleanly implemented within the pure Android PM. Thanks, Vitaly -- 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] [PATCH 0/8] Suspend block api (version 6)
On Monday 17 May 2010, Brian Swetland wrote: On Mon, May 17, 2010 at 11:39 AM, Felipe Balbi m...@felipebalbi.com wrote: ... but can anyone write an app that holds a suspend_blocker ?? If so, then your goal is already broken, right ? I mean, if anyone can keep a suspend_blocker held forever, you'll never ever sleep, right ? While with runtime, if you keep the keypad open, only the keypad and the paths directly related to it (probably the i2c controller and the power domain where the i2c controller sits) will be kept alive, no ? No, you'll never suspend, which is different from never going to the lowest CPU power state. On shipping Android devices we aggressively completely power down the CPU in idle whenever we can (based on latency requirements generally). We power off peripherals whenever they're not in use. This is why I've stated previously that I don't think runtime PM and opportunistic suspend are competitive features. Agreed. Everyone who cares about minimizing power should want runtime pm or at least similar functionality (our drivers have always powered down peripherals when not in use, even while the device is open, etc, prior to the existence of runtime PM). Yes. If your environment is such that going to full suspend will not gain you anything, then don't use opportunistic suspend. Exactly. We find that there are savings to be had with this model in Android which is why we use it. If you are going to use opportunistic suspend, suspend_blockers provide useful functionality. And as I said, I regard this as a legitimate approach to power management. 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] [PATCH 0/8] Suspend block api (version 6)
On Mon, May 17, 2010 at 1:17 PM, Vitaly Wool vitalyw...@gmail.com wrote: On Mon, May 17, 2010 at 10:07 PM, Mike Chan m...@android.com wrote: On Mon, May 17, 2010 at 12:27 PM, Vitaly Wool vitalyw...@gmail.com wrote: On Mon, May 17, 2010 at 6:12 PM, Kevin Hilman khil...@deeprootsystems.com wrote: and #2, the battery lifetime on the N770 and N800 (both of which I have) is **appalling** **bad**. Appalling bad compared to what? What's probably more interesting in terms of rough comparisons is comparing similar devices with and without opportunistic suspend. The Nokia n900 (maemo) and the Moto Droid (android) use the same SoC (TI OMAP3) and roughly the same kernel (2.6.2[89], although both are heavily patched from mainline.) The n900 *never* suspends. It only uses dynamic PM + CPUidle. The droid uses opportunistic suspend (as well as dynamic PM + CPUidle) I don't know of any more objective comparison of the two, but as a user of both devices I can say that the active usage is basically the same (around a day) and the idle use is similar as well, even though the Droid has a slightly bigger battery (1400 mAh vs. 1320 mAh.) My own usage suggests the n900 is a bit better in idle time, but I have not done any measuring or objective tests. I'm guessing the difference is probably because the Droid does not use the deepest off-mode power states either in idle or suspend (IIRC) where the n900 does. I suspect that if both were using off-mode and had the same battery, these differences would go away. Although both are OMAP3430 and run 2.6.29 you cannot compare the N900 and Droid's perceived user battery life to one another to evaluate opportunistic suspend. There are many factors uncounted for such as: network reception, screen brightness (and size), button back-light, keyboard back-light, modem stack (CDMA vs UMTS). Also the difference in uerspace. While this is not really a scientific comparison, it at least gives a rough idea. If using opportunistic suspend was adding noticably better battery life, I think this would be a different discussion. Okay, I measured with and without using the scientific method. With a 1390mAh battery, if you set your device in airplane mode you will get 435.7 hours of standby vs 397.14 hours of standby. Is this data sufficient for a different discussion now? Exactly. The point is, opportunistic suspend doesn't in fact add any value compared to dynamic PM + CPUIdle. It only produces some false impression that one can handle power management right without using dynamic PM. And this false impression is the cause for many really ugly designs (like, for instance, 15 minutes touchscreen inactivity delay before forcibly shutting down the wireless, as it's done in stock Android framework). Opportunistic suspend is an extension to the current suspend model, not a replacement dynamic / run-time PM. If you can replace good old suspend then this would be a different story. Yes, but what does it extend? What aspect it makes the current suspend model better in? Network configuration and cell reception is a big factor here. You can easily get +4-8mA on the original numbers I gave below, so its large enough to skew your perceived power usage. As you mention, Droid uses opportunistic suspend + dynamic pm + cpuidle + freq. So I decided to do some measurements on a Droid using our 2.9.32 kernel (http://android.git.kernel.org/?p=kernel/omap.git;a=summary). For a little better apples to apples comparison. Droid (idle system, airplane mode, screen off, 3 min interval): measured average current - with opportunity suspend: 3.19mA - without opportunistic suspend: 3.5mA Stock userspace build, all I did was replace the kernel. We are hitting retention on idle as well as suspend for omap (instead of full off-mode). That's implementation specific. If CPUIdle implemented CPU deep sleep, I bet you would see different figures. The important part here is not the absolute value, but how they compare relatively. If I added off-mode support then I the averages would both drop, but they would not be the same (key point). I simply wanted show with real numbers that there is a difference in opportunistic suspend and without. Instead of purely hypothesizing that there is no power benefit from using opportunistic suspend. Also, your point about wifi, the 15 min timeout is in the framework and is configurable in the code and via UI, nothing to do with kernel, opportunistic suspend or run time suspend. You don't quite get it :) This should NOT at all be timeout driven. This should be activity driven or constraint driven which perfectly fits into the runtime PM paradigm but is in no way cleanly implemented within the pure Android PM. I admit, our timeout approach is a bit hacky, but there is method for the madness. In order to properly determine when you should turn off wifi for perfect power management, you need to know a few
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
Mike Chan m...@android.com writes: On Mon, May 17, 2010 at 12:27 PM, Vitaly Wool vitalyw...@gmail.com wrote: On Mon, May 17, 2010 at 6:12 PM, Kevin Hilman khil...@deeprootsystems.com wrote: and #2, the battery lifetime on the N770 and N800 (both of which I have) is **appalling** **bad**. Appalling bad compared to what? What's probably more interesting in terms of rough comparisons is comparing similar devices with and without opportunistic suspend. The Nokia n900 (maemo) and the Moto Droid (android) use the same SoC (TI OMAP3) and roughly the same kernel (2.6.2[89], although both are heavily patched from mainline.) The n900 *never* suspends. It only uses dynamic PM + CPUidle. The droid uses opportunistic suspend (as well as dynamic PM + CPUidle) I don't know of any more objective comparison of the two, but as a user of both devices I can say that the active usage is basically the same (around a day) and the idle use is similar as well, even though the Droid has a slightly bigger battery (1400 mAh vs. 1320 mAh.) My own usage suggests the n900 is a bit better in idle time, but I have not done any measuring or objective tests. I'm guessing the difference is probably because the Droid does not use the deepest off-mode power states either in idle or suspend (IIRC) where the n900 does. I suspect that if both were using off-mode and had the same battery, these differences would go away. Although both are OMAP3430 and run 2.6.29 you cannot compare the N900 and Droid's perceived user battery life to one another to evaluate opportunistic suspend. There are many factors uncounted for such as: network reception, screen brightness (and size), button back-light, keyboard back-light, modem stack (CDMA vs UMTS). Also the difference in uerspace. Agreed. I was reluctant to even make the comparison for all those reasons, but with the lack of real numbers, it was all I had to show a very rough subjective guess, and at least show that with and without opportunistic suspend, you're in the same ballpark. While this is not really a scientific comparison, it at least gives a rough idea. If using opportunistic suspend was adding noticably better battery life, I think this would be a different discussion. Exactly. The point is, opportunistic suspend doesn't in fact add any value compared to dynamic PM + CPUIdle. It only produces some false impression that one can handle power management right without using dynamic PM. And this false impression is the cause for many really ugly designs (like, for instance, 15 minutes touchscreen inactivity delay before forcibly shutting down the wireless, as it's done in stock Android framework). Opportunistic suspend is an extension to the current suspend model, not a replacement dynamic / run-time PM. If you can replace good old suspend then this would be a different story. As you mention, Droid uses opportunistic suspend + dynamic pm + cpuidle + freq. So I decided to do some measurements on a Droid using our 2.9.32 kernel (http://android.git.kernel.org/?p=kernel/omap.git;a=summary). For a little better apples to apples comparison. Excellent. Thanks for some real numbers. (btw, sure would be nice to have the basic droid board files in mainline. ;) Droid (idle system, airplane mode, screen off, 3 min interval): measured average current - with opportunity suspend: 3.19mA - without opportunistic suspend: 3.5mA Stock userspace build, all I did was replace the kernel. We are hitting retention on idle as well as suspend for omap (instead of full off-mode). [at risk of stating the obvious] Since both approaches hit the same power states, if the system was truly idle, you'd expect the numbers to be the same, right? So what the difference shows is that the system is not fully idle, IOW userspace and/or kernel wakeups are cusing the difference. It might also be instructive to see these numbers with a noop userspace, like just booting into busybox init=/bin/sh (or the android equivalent.) That would show how much of that difference is due to kernel idleness (or lack thereof.) Even still, to me this all boils down to the lack of definition of the problem and clear description of the solution The fundamental problem is one of idleness. What we want is the system to be idle in order to hit the lowest power states. We can't get there because the system is not truly idle. So, there are basically two solutions: 1) find and fix the problem spots so we can be idle more often 2) add a new definition of idle so we can be idle more often Opporuntistic suspend takes the second approach where the new definition of idle is no suspend blockers held. Of course, I clearly prefer the former, but it's also becoming clear that since I'm the only one still whining about it, I must be too much of an idealist to keep hoping for it. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Mon, May 17, 2010 at 3:55 PM, Kevin Hilman khil...@deeprootsystems.com wrote: The fundamental problem is one of idleness. What we want is the system to be idle in order to hit the lowest power states. We can't get there because the system is not truly idle. So, there are basically two solutions: 1) find and fix the problem spots so we can be idle more often 2) add a new definition of idle so we can be idle more often Opporuntistic suspend takes the second approach where the new definition of idle is no suspend blockers held. Of course, I clearly prefer the former, but it's also becoming clear that since I'm the only one still whining about it, I must be too much of an idealist to keep hoping for it. I'd love to see the former work, but it is not something that I think is going to be fixed rapidly. It potentially involves many different subsystems, and still requires some need for managing arbitrary userspace agents which may have non-ideal behaviors (if we're going to solve the problem for general purpose devices that can run arbitrary user-installed software). Incremental improvements are great though (for example, that we can now be in lowest power idle for periods greater than 2 seconds due to the change in .32). Even when operating in opportunistic suspend, it is still advantageous for idle to be as idle as possible and we should keep working toward that goal. If we get to the point where the power difference between suspend-in-idle and opportunistic suspend is zero, then we no longer need the latter. I don't think anybody on the Google/Android side is arguing that we *shouldn't* pursue dynamic pm and overall making idle more idle more of the time. We're just saying that here and now we are not at the ideal and opportunistic suspend gains us real power savings and is useful. Brian -- 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] [PATCH 0/8] Suspend block api (version 6)
On Sat, 2010-05-15 at 22:14 +0200, Rafael J. Wysocki wrote: On Saturday 15 May 2010, Kevin Hilman wrote: Rafael J. Wysocki r...@sisk.pl writes: On Friday 14 May 2010, Kevin Hilman wrote: If it truly is the lack of a suspend blocker API that is preventing the merge of these out of tree drivers, I second Mark's proposal[1] to merge a noop version of the API while the technical issues continue to be discussed. I'm against that, sorry. OK, I'll bite... Why? Because in that case the real feature will always be opposed as unnecessary and never merged. I very much prefer to decide whether to merge it or reject it right now. FWIW (as the person who made the suggestion) I do think that it is something one might call expedient rather than actually good. It was expressed because I find the arguments above for merging because it prevents out-of-tree drivers from merging quite unconvincing. This is not just about opportunistic suspend + suspend blockers specifically but comes from several years experience in the embedded Linux world. In this particular case, the lack of the mainline's support for opportunistic suspend (in the form of wakelocks to be precise) has been given as a main obstacle against merging of several drivers at least. Where are these objections coming from? The only example I've seen cited is the G1 stuff, which is a fairly special case for a number of reasons (including the underlying MSM BSP, which was pretty substantial itself). And this is not the only reason to push the opportunistic suspend feature upstream IMO. Agreed, my purpose here is mostly to push back on what sound like unrealistic expectations about what we're getting. Second, (as said above) there is a number of drivers _already_ depending on it and that number is only going to grow given the popularity of Android. They are not mainlined in part because their authors don't see a benefit from doing so (usually the benefit is that you don't have to maintain your code out of the tree, because the mainline does it for you to some extent, so if you need to maintain a separate version yourself, the benefit is zero). Wakelocks are going to be a fairly minor part of any decision here - it'd be pretty surprising if they take much effort to remove from a driver. What's much more of an issue is that you've got essentially the same situation as you have with the enterprise Linux distributions, a fixed kernel version that vendors need to target. The differences that implies are far more substantial than wakelocks for many areas of the kernel, especially at the points in the cycle where the fixed kernel has drifted furthest from the current mainline. Things aren't quite the same as with the enterprise distributions, though - the lifecycles for many parts in the consumer space are much, much shorter than those in the enterprise markets. They can be sufficiently short to mean that a mainline driver won't show up where customers need it soon enough. For example, Google is currently preparing an Android release based on 2.6.32 the merge window for which was in September last year, over six months ago. This is an extremely long latency if you're working on something in the region of a twelve month cycle. The lack of standardisation for register interfaces in the embedded space means that the generation to generation differences can easily be sufficiently substantial to make a new driver the only sensible option. This isn't to say that the old parts just suddenly vanish, and clearly there's an advantage from ongoing mainline inclusion, but the tradeoffs are a bit different to those in other markets. There's also a less pressure from end users towards mainline inclusion - even on Linux people in the embedded space are used to having to get code from multiple vendors working together so the lack of mainline support isn't the sort of issue it would be with something like server class hardware. This is changing over time as more and more vendors buy into mainline but there's a way to go yet. If the part requires changes outside the driver itself (a new or updated kernel interface, for example) there's a pressure to just deal with it in the driver in a way which is going to be unacceptable for mainline, possibly even involving per-system code modifications in the driver. Sometimes ongoing mainline development will mean that the driver needs updating anyway in ways that are much more substantial than ripping out wakelocks would be. Having wakelocks in does make things easier for drivers using them but we need to recognise that all sorts of other things that are much harder to deal with will also come up. -- 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 02:34:55PM -0700, Tony Lindgren wrote: * Matthew Garrett m...@redhat.com [100513 14:16]: What race-free mechanism do you use to ensure that? It's very easy to handwave these problems away. It's very difficult to actually write an implementation that works. Can you describe where do you see the race now? 1) Trusted app decides to suspend 2) Network packet that would otherwise wake the system is received 3) Trusted app sends SIGSTOP to untrusted userspace 4) Network packet sits waiting for stopped userspace to process it Unless the trusted userspace gets woken up on every event that would potentially cause a wakeup, you're racy. And the alternative involves an extra userspace wakeup for every network packet - which is expensive. -- Matthew Garrett | mj...@srcf.ucam.org -- 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] [PATCH 0/8] Suspend block api (version 6)
On Fri, 14 May 2010, Brian Swetland wrote: In tickless mode, the time until next timer is a signed int, so the longest the kernel will ever sleep is ~2 seconds at a go. In practice, userspace entities often have polling behavior that can trigger more often than that, and I've observed some kernel periodic timers (haven't cataloged them recently) that happen more often than once a second. Paul and Kevin, how does the OMAP implementation handle these difficulties? Also, how does it handle the issue of ill-behaved apps? 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] [PATCH 0/8] Suspend block api (version 6)
On Saturday 15 May 2010, Kevin Hilman wrote: Rafael J. Wysocki r...@sisk.pl writes: On Friday 14 May 2010, Kevin Hilman wrote: Kevin Hilman khil...@deeprootsystems.com writes: Rafael J. Wysocki r...@sisk.pl writes: On Thursday 13 May 2010, Tony Lindgren wrote: * Rafael J. Wysocki r...@sisk.pl [100513 14:16]: [...] It solves a practical issue that _at_ _the_ _moment_ cannot be solved differently, while there's a growing number of out-of-tree drivers depending on this framework. We need those drivers in and because we don't have any viable alternative at hand, we have no good reason to reject it. Nothing is preventing merging the drivers can be merged without these calls. And yet, there _is_ a growing nuber of drivers that don't get merge because of that. That's _reality_. Are you going to discuss with facts, or what? It may be reality, but IMO, preventing other drivers isn't a good *technical* argument for merging a feature. It feels like these for the 'good' of the community arguments are being used to trump the technical arguments. Maybe we need to keep the separate. To continue along the for the good of the community path... If it truly is the lack of a suspend blocker API that is preventing the merge of these out of tree drivers, I second Mark's proposal[1] to merge a noop version of the API while the technical issues continue to be discussed. I'm against that, sorry. OK, I'll bite... Why? Because in that case the real feature will always be opposed as unnecessary and never merged. I very much prefer to decide whether to merge it or reject it right now. Then we would see how many drivers get submitted and merged. Personally, I suspect that lack of this feature is not the real obstacle to getting these out-of-tree drivers upstream. Having this API upstream will not change the product schedules and corporate cultures that have prevented code from making its way upstream. But apparently it is considered as a suitable excuse. No, it is not a _technical_ excuse. Just a healthy, experience-based dose of skepticism. I didn't mean that, actually. What I wanted to say is that people use the lack of wakelocks in the mainline as an excuse not to push their drivers upstream (which is kind of understandable, because there's a zero benefit to them from mainlining their code, as they will have to maintain a separate Android version of it anyway). Sorry for the confusion. It was expressed because I find the arguments above for merging because it prevents out-of-tree drivers from merging quite unconvincing. This is not just about opportunistic suspend + suspend blockers specifically but comes from several years experience in the embedded Linux world. In this particular case, the lack of the mainline's support for opportunistic suspend (in the form of wakelocks to be precise) has been given as a main obstacle against merging of several drivers at least. So, let's not just easily generalize, please. And this is not the only reason to push the opportunistic suspend feature upstream IMO. First, I think it is a legitimate approach to power management, whether you like it or not. I haven't seen anyone seriously arguing against that yet. Second, (as said above) there is a number of drivers _already_ depending on it and that number is only going to grow given the popularity of Android. They are not mainlined in part because their authors don't see a benefit from doing so (usually the benefit is that you don't have to maintain your code out of the tree, because the mainline does it for you to some extent, so if you need to maintain a separate version yourself, the benefit is zero). Next, the only thing the Arve's patches do is to give people an _option_ to use opportunistic suspend if they need it or want it. It's not mandatory and not even enabled by default, so I don't really see what the problem is. Quite on the contrary, I'd like people to be able to use the mainline on Android systems without major modifications, because potentially that can increase our tester base (and developer base too in consequence) and including opportunistic suspend in the mainline would be a step in that direction. Finally, it appears to address some issues that at the moment we don't seriously know how to address in a different way. 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] [PATCH 0/8] Suspend block api (version 6)
Matthew Garrett m...@redhat.com writes: On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote: The system stays running because there's something to do. The system won't suspend until all the processors hit the kernel idle loop and the next_timer_interrupt_critical() returns nothing. At which point an application in a busy loop cripples you. I think we could implement your suggestion more easily by just giving untrusted applications an effectively infinite amount of timer slack, but it still doesn't handle the case where an app behaves excrutiatingly badly. Is design for exruciatingly bad apps a design requirement? If so, opportunistic suspend + suspend blockers fails as well. An app could easily hold a suspend blocker during its entire execution crippling PM. Using opportunistic suspend may possibly allow you contain bad apps/drivers, but at the cost of having to patch already working and trusted apps and known-working kernel code with suspend blockers. IMO, rather than accepting a solution that allows bad apps to run wild, it would be much better to _continue_ focus on tools for finding and containing bad apps. This approach has the added bonus of solving problems on *every* linux-based system, not just Android. Kevin -- 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, 2010-05-13 at 14:46 -0700, Greg KH wrote: On Thu, May 13, 2010 at 02:33:29PM -0700, Daniel Walker wrote: On Thu, 2010-05-13 at 23:27 +0200, Rafael J. Wysocki wrote: Because someone would have to remove suspend blockers (or rather wakelocks) from the drivers, test that they work correctly without suspend blockers and submit the modified versions. Going forward, every party responsible for such a driver would have to maintain an out-of-tree version with suspend blockers (or wakelocks) anyway, so the incentive to do that is zero. They should work without wakelock since wakelock are optional .. I mean there's nothing in suspend blockers I've seen that indicates it's required for some drivers to work. So it's just a matter of patching out the wakelocks, with no need to re-test anything. You get the driver mainlined, then maintain a small patch to add wakelocks. Not hard at all , with lots of incentive to do so since you don't have to maintain such a large block of code out of tree. Sorry, but it doesn't seem to work that way. Look at the large number of out-of-tree android device drivers that remain sitting there because of the lack of this interface being in the kernel. I don't think that's due to this interface tho. During your CELF presentation you noted several bits of code that could go in right now but haven't (and still haven't as far as I've seen). I'm actively pushing code related to Android (with wakelocks removed).. Putting a wakelock contingency on everything to me doesn't make much sense. Also note that such a driver, without wakelocks, would never get tested, and so, things start quickly diverging. That's not totally true. For example the MMC driver had wakelocks (I think, or for sure mmc core does), and the MMC driver has been tested for G1 and works fine so far without them. I have code that is queued for my tree that will enable MMC on G1. I can merge Nexus one support through my tree also which would allow all the drivers for that device to eventually be used. With that device support in mainline then those drivers become nice things to have with or with out wakelocks. You don't need wakelocks to run Debian or anything else except Android. Daniel -- 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] [PATCH 0/8] Suspend block api (version 6)
On Friday 14 May 2010, Kevin Hilman wrote: Rafael J. Wysocki r...@sisk.pl writes: On Thursday 13 May 2010, Tony Lindgren wrote: * Rafael J. Wysocki r...@sisk.pl [100513 14:16]: [...] It solves a practical issue that _at_ _the_ _moment_ cannot be solved differently, while there's a growing number of out-of-tree drivers depending on this framework. We need those drivers in and because we don't have any viable alternative at hand, we have no good reason to reject it. Nothing is preventing merging the drivers can be merged without these calls. And yet, there _is_ a growing nuber of drivers that don't get merge because of that. That's _reality_. Are you going to discuss with facts, or what? It may be reality, but IMO, preventing other drivers isn't a good *technical* argument for merging a feature. It feels like these for the 'good' of the community arguments are being used to trump the technical arguments. Maybe we need to keep the separate. Distros (especially embedded ones) have long had out of tree features that create barriers to getting other drivers upstream. While it might be nice to see all those features upstream, no one has argued that they should get merged simply because they create a barrier. Each feature should be merged on its own technical merit. Well, this is very much like the selinux vs apparmour ( friends) issue. One can argue we need only one of them, but in fact we're not worse off having both in. The feature is not technically unacceptable to me and since having it in would potentially make it easier to merge quite a few drivers, I regard that as a good enough argument for. YMMV. 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] [PATCH 0/8] Suspend block api (version 6)
Kevin Hilman khil...@deeprootsystems.com writes: Rafael J. Wysocki r...@sisk.pl writes: On Thursday 13 May 2010, Tony Lindgren wrote: * Rafael J. Wysocki r...@sisk.pl [100513 14:16]: [...] It solves a practical issue that _at_ _the_ _moment_ cannot be solved differently, while there's a growing number of out-of-tree drivers depending on this framework. We need those drivers in and because we don't have any viable alternative at hand, we have no good reason to reject it. Nothing is preventing merging the drivers can be merged without these calls. And yet, there _is_ a growing nuber of drivers that don't get merge because of that. That's _reality_. Are you going to discuss with facts, or what? It may be reality, but IMO, preventing other drivers isn't a good *technical* argument for merging a feature. It feels like these for the 'good' of the community arguments are being used to trump the technical arguments. Maybe we need to keep the separate. To continue along the for the good of the community path... If it truly is the lack of a suspend blocker API that is preventing the merge of these out of tree drivers, I second Mark's proposal[1] to merge a noop version of the API while the technical issues continue to be discussed. Then we would see how many drivers get submitted and merged. Personally, I suspect that lack of this feature is not the real obstacle to getting these out-of-tree drivers upstream. Having this API upstream will not change the product schedules and corporate cultures that have prevented code from making its way upstream. Kevin [1] https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025501.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] [PATCH 0/8] Suspend block api (version 6)
On Friday 14 May 2010, Kevin Hilman wrote: Kevin Hilman khil...@deeprootsystems.com writes: Rafael J. Wysocki r...@sisk.pl writes: On Thursday 13 May 2010, Tony Lindgren wrote: * Rafael J. Wysocki r...@sisk.pl [100513 14:16]: [...] It solves a practical issue that _at_ _the_ _moment_ cannot be solved differently, while there's a growing number of out-of-tree drivers depending on this framework. We need those drivers in and because we don't have any viable alternative at hand, we have no good reason to reject it. Nothing is preventing merging the drivers can be merged without these calls. And yet, there _is_ a growing nuber of drivers that don't get merge because of that. That's _reality_. Are you going to discuss with facts, or what? It may be reality, but IMO, preventing other drivers isn't a good *technical* argument for merging a feature. It feels like these for the 'good' of the community arguments are being used to trump the technical arguments. Maybe we need to keep the separate. To continue along the for the good of the community path... If it truly is the lack of a suspend blocker API that is preventing the merge of these out of tree drivers, I second Mark's proposal[1] to merge a noop version of the API while the technical issues continue to be discussed. I'm against that, sorry. Then we would see how many drivers get submitted and merged. Personally, I suspect that lack of this feature is not the real obstacle to getting these out-of-tree drivers upstream. Having this API upstream will not change the product schedules and corporate cultures that have prevented code from making its way upstream. But apparently it is considered as a suitable excuse. 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] [PATCH 0/8] Suspend block api (version 6)
Rafael J. Wysocki r...@sisk.pl writes: On Friday 14 May 2010, Kevin Hilman wrote: Kevin Hilman khil...@deeprootsystems.com writes: Rafael J. Wysocki r...@sisk.pl writes: On Thursday 13 May 2010, Tony Lindgren wrote: * Rafael J. Wysocki r...@sisk.pl [100513 14:16]: [...] It solves a practical issue that _at_ _the_ _moment_ cannot be solved differently, while there's a growing number of out-of-tree drivers depending on this framework. We need those drivers in and because we don't have any viable alternative at hand, we have no good reason to reject it. Nothing is preventing merging the drivers can be merged without these calls. And yet, there _is_ a growing nuber of drivers that don't get merge because of that. That's _reality_. Are you going to discuss with facts, or what? It may be reality, but IMO, preventing other drivers isn't a good *technical* argument for merging a feature. It feels like these for the 'good' of the community arguments are being used to trump the technical arguments. Maybe we need to keep the separate. To continue along the for the good of the community path... If it truly is the lack of a suspend blocker API that is preventing the merge of these out of tree drivers, I second Mark's proposal[1] to merge a noop version of the API while the technical issues continue to be discussed. I'm against that, sorry. OK, I'll bite... Why? Then we would see how many drivers get submitted and merged. Personally, I suspect that lack of this feature is not the real obstacle to getting these out-of-tree drivers upstream. Having this API upstream will not change the product schedules and corporate cultures that have prevented code from making its way upstream. But apparently it is considered as a suitable excuse. No, it is not a _technical_ excuse. Just a healthy, experience-based dose of skepticism. It was expressed because I find the arguments above for merging because it prevents out-of-tree drivers from merging quite unconvincing. This is not just about opportunistic suspend + suspend blockers specifically but comes from several years experience in the embedded Linux world. Kevin -- 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] [PATCH 0/8] Suspend block api (version 6)
On Fri, 14 May 2010, Rafael J. Wysocki wrote: How do you handle situations where the CPU is currently idle but an event (such as I/O completion) is expected to occur in the near future? You don't want to power-off and reboot then, do you? The idle code looks at next_timer_interrupt() value, then if the next timer event if far enough ahead, the system powers down and wakes to the timer interrupt. It also wakes to device interrupts. For the record, waking to interrupts doesn't work on quite some systems (like ACPI-based PCs for one example). Ironically, it appears that ACPI-based PCs are in a position to benefit more from opportunistic suspend and suspend blockers than are embedded systems -- and yet they are being proposed for use on cell phones rather than on desktops. 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] [PATCH 0/8] Suspend block api (version 6)
On Fri, 14 May 2010, Magnus Damm wrote: I agree with you Tony. I thought shutting down CPUs for power managment purposes could be done without freezing user space. At least that's what we do today with SH-Mobile. If you can shut down and restart CPUs in the time periods between transitions into and out of the idle loop, then yes -- userspace doesn't need to be suspended. After all, if the idle loop is running then no user threads are runnable. (Not necessarily true on SMP systems, but you know what I mean.) Still not sure how the system wide suspend is different from Runtime PM and CPUidle from the hardware perspective... For embedded systems, apparently the difference is minimal. For other systems, like ACPI-based PCs, there is a big difference: Powering down devices and CPUs still leaves large parts of the system running. In addition, these larger systems generally don't have aggressive runtime PM support, so a significant fraction (maybe more than 50%) of devices won't be powered down when they are idle -- whereas system suspend powers virtually everything down. 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] [PATCH 0/8] Suspend block api (version 6)
On Fri, 14 May 2010, Brian Swetland wrote: It provides useful functionality -- you apparently disagree, but the wakelock/suspendblock model is in use, shipping, and solving problems for quite a lot of android devices that have been shipping for a while now. We actively go to lowest power state in idle (on omap, msm, etc), and use drivers that aggressively declock and depower modules (similar to runtime pm), but we have found that using the opportunistic suspend model combined with wakelocks allows us to attain even lower average power consumption in always-connected, actively-syncing devices. Can you explain this in more detail? Are you saying that some devices go on generating interrupts and causing timers to be scheduled, even though what they're doing isn't important enough to prevent the system from powering down? 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] [PATCH 0/8] Suspend block api (version 6)
On Fri, May 14, 2010 at 7:58 PM, Alan Stern st...@rowland.harvard.edu wrote: On Fri, 14 May 2010, Brian Swetland wrote: It provides useful functionality -- you apparently disagree, but the wakelock/suspendblock model is in use, shipping, and solving problems for quite a lot of android devices that have been shipping for a while now. We actively go to lowest power state in idle (on omap, msm, etc), and use drivers that aggressively declock and depower modules (similar to runtime pm), but we have found that using the opportunistic suspend model combined with wakelocks allows us to attain even lower average power consumption in always-connected, actively-syncing devices. Can you explain this in more detail? Are you saying that some devices go on generating interrupts and causing timers to be scheduled, even though what they're doing isn't important enough to prevent the system from powering down? In tickless mode, the time until next timer is a signed int, so the longest the kernel will ever sleep is ~2 seconds at a go. In practice, userspace entities often have polling behavior that can trigger more often than that, and I've observed some kernel periodic timers (haven't cataloged them recently) that happen more often than once a second. When we go to full suspend, we know that only specific wakeup sources (keyboard gpios, baseband voice/ip events, rtc alarms, etc) are going to wake us up. Brian -- 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] [PATCH 0/8] Suspend block api (version 6)
On Fri, May 14, 2010 at 7:35 PM, Alan Stern st...@rowland.harvard.edu wrote: On Fri, 14 May 2010, Rafael J. Wysocki wrote: How do you handle situations where the CPU is currently idle but an event (such as I/O completion) is expected to occur in the near future? You don't want to power-off and reboot then, do you? The idle code looks at next_timer_interrupt() value, then if the next timer event if far enough ahead, the system powers down and wakes to the timer interrupt. It also wakes to device interrupts. For the record, waking to interrupts doesn't work on quite some systems (like ACPI-based PCs for one example). Ironically, it appears that ACPI-based PCs are in a position to benefit more from opportunistic suspend and suspend blockers than are embedded systems -- and yet they are being proposed for use on cell phones rather than on desktops. I would also use it on a desktop. -- 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] [PATCH 0/8] Suspend block api (version 6)
On Wed, May 12, 2010 at 09:35:30PM -0600, Paul Walmsley wrote: Figuring out a different way to do this should not limit Android at all, since Google can do what other Linux distributions do and continue to patch opportunistic suspend/suspend-block calls into their kernels as needed to ship devices, while contributing towards a different solution to the problem. I basically agree, except that despite having a year to do so none of us have come up with a different way that would actually work. Google have done this work. Who's going to prove that there is actually a different way to do this? -- Matthew Garrett | mj...@srcf.ucam.org -- 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, 2010-05-13 at 13:17 +0100, Matthew Garrett wrote: On Wed, May 12, 2010 at 09:35:30PM -0600, Paul Walmsley wrote: Figuring out a different way to do this should not limit Android at all, since Google can do what other Linux distributions do and continue to patch opportunistic suspend/suspend-block calls into their kernels as needed to ship devices, while contributing towards a different solution to the problem. I basically agree, except that despite having a year to do so none of us have come up with a different way that would actually work. Google have done this work. Who's going to prove that there is actually a different way to do this? We all feel the pain of inelegance right? I think it's clear that this system will not last (but there's no other immediate option) .. That doesn't mean we should reject it, but we need to be clear that this system will get replaced. So we should format the patches appropriately. To me the userspace aspect is a permanent change .. If we could drop that (or put it into debugfs) then it would make this a lot easy to accept as a stepping stone. Daniel -- 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 10:33 AM, Daniel Walker dwal...@fifo99.com wrote: On Thu, 2010-05-13 at 13:17 +0100, Matthew Garrett wrote: On Wed, May 12, 2010 at 09:35:30PM -0600, Paul Walmsley wrote: Figuring out a different way to do this should not limit Android at all, since Google can do what other Linux distributions do and continue to patch opportunistic suspend/suspend-block calls into their kernels as needed to ship devices, while contributing towards a different solution to the problem. I basically agree, except that despite having a year to do so none of us have come up with a different way that would actually work. Google have done this work. Who's going to prove that there is actually a different way to do this? We all feel the pain of inelegance right? I think it's clear that this system will not last (but there's no other immediate option) .. That doesn't mean we should reject it, but we need to be clear that this system will get replaced. So we should format the patches appropriately. To me the userspace aspect is a permanent change .. If we could drop that (or put it into debugfs) then it would make this a lot easy to accept as a stepping stone. I'm in agreement on the first half of this -- from the Google/Android point of view, if we can someday accomplish everything we need with some different facility, we'll happily shift over to that. That seems like a normal operating mode for mainline -- new solutions arise, drivers are migrated to those new solutions, old solutions fall to the wayside. We fully expect that the world will change over time and one of our largest goals with trying to get work upstream is to reduce the pain of those changes for everyone, while trying to get to you can build a kernel out of the box from mainline that Just Works with an android userspace. I'm not sure this necessitates using only debugfs for the userspace interface. A userspace interface is necessary to accomplish what we're trying to do here, otherwise we have only half a solution, and our hope is that it'd be a stable interface (as userspace interfaces are supposed to be) for as long as its needed. I could totally imagine the userspace interface eventually becoming a no-op or punching through to some other facility, depending on how this problem is solved long-term in the ideal post-suspend-block future. Brian -- 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, 2010-05-13 at 11:17 -0700, Brian Swetland wrote: I'm not sure this necessitates using only debugfs for the userspace interface. A userspace interface is necessary to accomplish what we're trying to do here, otherwise we have only half a solution, and our hope is that it'd be a stable interface (as userspace interfaces are supposed to be) for as long as its needed. I could totally imagine the userspace interface eventually becoming a no-op or punching through to some other facility, depending on how this problem is solved long-term in the ideal post-suspend-block future. The problem is that once this userspace interface is exposed, it's nearly permanent and has to be support for a long long time .. It might seen trivial to just remove something your not using, but we never know who is using what once the kernel is released. Daniel -- 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 11:25:57AM -0700, Daniel Walker wrote: The problem is that once this userspace interface is exposed, it's nearly permanent and has to be support for a long long time .. It might seen trivial to just remove something your not using, but we never know who is using what once the kernel is released. Deprecating sysfs interfaces can be done within 6 months or so, especially if there's only one real consumer. -- Matthew Garrett | mj...@srcf.ucam.org -- 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, 2010-05-13 at 19:36 +0100, Matthew Garrett wrote: On Thu, May 13, 2010 at 11:25:57AM -0700, Daniel Walker wrote: The problem is that once this userspace interface is exposed, it's nearly permanent and has to be support for a long long time .. It might seen trivial to just remove something your not using, but we never know who is using what once the kernel is released. Deprecating sysfs interfaces can be done within 6 months or so, especially if there's only one real consumer. I'll assume your right (can you give an example of this?), but why should we even add it if we know it's already going to get replaced. It's like it's pre-deprecated .. Daniel -- 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 11:59:37AM -0700, Daniel Walker wrote: On Thu, 2010-05-13 at 19:36 +0100, Matthew Garrett wrote: Deprecating sysfs interfaces can be done within 6 months or so, especially if there's only one real consumer. I'll assume your right (can you give an example of this?), but why should we even add it if we know it's already going to get replaced. It's like it's pre-deprecated .. See feature-removal-schedule.txt. So far we have no indication that it's going to be replaced, because nobody has actually suggested a working way to do this better. If we had a concrete implementation proposal for that then we'd be in a pretty different position right now. -- Matthew Garrett | mj...@srcf.ucam.org -- 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] [PATCH 0/8] Suspend block api (version 6)
* Alan Stern st...@rowland.harvard.edu [100513 07:11]: On Wed, 12 May 2010, Paul Walmsley wrote: Hello, Some general comments on the suspend blockers/wakelock/opportunistic suspend v6 patch series, posted here: https://lists.linux-foundation.org/pipermail/linux-pm/2010-April/025146.html The comments below are somewhat telegraphic in the interests of readability - more specific comments to follow in later E-mails. I am indebted to those of us who discussed these issues at LPC last year and ELC this year for several stimulating discussions. There are several general problems with the design of opportunistic suspend and suspend-blocks. 1. The opportunistic suspend code bypasses existing Linux kernel code, such as timers and the scheduler, that indicates when code needs to run, and when the system is idle. Whoa! That's not my understanding at all. As I see it, opportunistic suspend doesn't bypass any code that isn't already bypassed by the existing suspend code. Users can do echo mem /sys/power/state whenever they want, without regard to kernel timers and the scheduler (other than the fact that the user's thread must be running in order to carry out the write, of course). The difference between echo mem /sys/power/state and suspend blocks is that with suspend blocks the system keeps running. And that's why it should be handled by runtime power management instead. The suspend blocks seems like a hack to spam filter good and bad apps from timer usage point of view. Applications are categorized as good or bad depending if they grab a susped blocker or not. I believe categorizing the apps should be instead done with some timer flags or cgroups instead. Cheers, 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 12:17:17PM -0700, Tony Lindgren wrote: The suspend blocks seems like a hack to spam filter good and bad apps from timer usage point of view. Applications are categorized as good or bad depending if they grab a susped blocker or not. I believe categorizing the apps should be instead done with some timer flags or cgroups instead. I agree, but we have no mechanism for implementing that in a race-free way. We don't even have a realistical proposal for what that mechanism would look like. Should we refuse bread today for the promise of cake tomorrow? -- Matthew Garrett | mj...@srcf.ucam.org -- 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, 2010-05-13 at 20:11 +0100, Matthew Garrett wrote: On Thu, May 13, 2010 at 11:59:37AM -0700, Daniel Walker wrote: On Thu, 2010-05-13 at 19:36 +0100, Matthew Garrett wrote: Deprecating sysfs interfaces can be done within 6 months or so, especially if there's only one real consumer. I'll assume your right (can you give an example of this?), but why should we even add it if we know it's already going to get replaced. It's like it's pre-deprecated .. See feature-removal-schedule.txt. So far we have no indication that it's going to be replaced, because nobody has actually suggested a working way to do this better. If we had a concrete implementation proposal for that then we'd be in a pretty different position right now. Ok, feature-removal-schedule.txt applies to everything tho. What your saying is that if this interface only last a short time it might take 6 months, if it last for a long time it would take longer. There's no easy way to know that Google is the only user after some amount of time passes. Daniel -- 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] [PATCH 0/8] Suspend block api (version 6)
* Matthew Garrett m...@redhat.com [100513 12:20]: On Thu, May 13, 2010 at 12:17:17PM -0700, Tony Lindgren wrote: The suspend blocks seems like a hack to spam filter good and bad apps from timer usage point of view. Applications are categorized as good or bad depending if they grab a susped blocker or not. I believe categorizing the apps should be instead done with some timer flags or cgroups instead. I agree, but we have no mechanism for implementing that in a race-free way. We don't even have a realistical proposal for what that mechanism would look like. Should we refuse bread today for the promise of cake tomorrow? Well this is an interesting problem, and once solved will be handy for all kind of things. My worry is that if it's integrated in it's current form it will be totally out of control all over the place :( Still hoping we can come up with some clean way that avoid the patching all over the place part.. How about the following, can you please check if it would help with your example of guaranteed handling of event: 1. In the kernel, we add one more timer queue for critical timers. The current timer queue(s) stay as it is. 2. We allow selecting the timer based on some flag, the default behaviour being the current default timer queue. 3. Then we add next_timer_interupt_critical() to only query the critical timers along the lines of the current next_timer_interrupt(). 4. We implement a custom pm_idle that suspends the system based on some logic and checking if next_timer_interrupt_critical() is empty. If the next_timer_interrupt_critical() does not return anything, we assume it's OK to suspend the system. Now to me it sounds if your the input layer and userspace handle both grab the timers with the critical flags, it should be guaranteed that the events get handled before the system is suspended. 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 12:36:34PM -0700, Daniel Walker wrote: On Thu, 2010-05-13 at 20:11 +0100, Matthew Garrett wrote: See feature-removal-schedule.txt. So far we have no indication that it's going to be replaced, because nobody has actually suggested a working way to do this better. If we had a concrete implementation proposal for that then we'd be in a pretty different position right now. Ok, feature-removal-schedule.txt applies to everything tho. What your saying is that if this interface only last a short time it might take 6 months, if it last for a long time it would take longer. There's no easy way to know that Google is the only user after some amount of time passes. If the interface is there for a long time, it's because we haven't come up with anything better. And if we haven't come up with anything better, the interface deserves to be there. -- Matthew Garrett | mj...@srcf.ucam.org -- 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 12:42:05PM -0700, Tony Lindgren wrote: 1. In the kernel, we add one more timer queue for critical timers. The current timer queue(s) stay as it is. 2. We allow selecting the timer based on some flag, the default behaviour being the current default timer queue. 3. Then we add next_timer_interupt_critical() to only query the critical timers along the lines of the current next_timer_interrupt(). 4. We implement a custom pm_idle that suspends the system based on some logic and checking if next_timer_interrupt_critical() is empty. If the next_timer_interrupt_critical() does not return anything, we assume it's OK to suspend the system. Ok. So we stick the untrusted bits of userspace on the critical timer list. Now we get a network packet that generates a wakeup event and gets read by an application. What happens if that application can't fully process the packet in a single timeslice? -- Matthew Garrett | mj...@srcf.ucam.org -- 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] [PATCH 0/8] Suspend block api (version 6)
* Matthew Garrett m...@redhat.com [100513 12:49]: On Thu, May 13, 2010 at 12:42:05PM -0700, Tony Lindgren wrote: 1. In the kernel, we add one more timer queue for critical timers. The current timer queue(s) stay as it is. 2. We allow selecting the timer based on some flag, the default behaviour being the current default timer queue. 3. Then we add next_timer_interupt_critical() to only query the critical timers along the lines of the current next_timer_interrupt(). 4. We implement a custom pm_idle that suspends the system based on some logic and checking if next_timer_interrupt_critical() is empty. If the next_timer_interrupt_critical() does not return anything, we assume it's OK to suspend the system. Ok. So we stick the untrusted bits of userspace on the critical timer list. I guess you mean the trusted instead of untrusted apps in the userspace above, the ones that are critical to keep running. Now we get a network packet that generates a wakeup event and gets read by an application. What happens if that application can't fully process the packet in a single timeslice? The system stays running because there's something to do. The system won't suspend until all the processors hit the kernel idle loop and the next_timer_interrupt_critical() returns nothing. 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote: The system stays running because there's something to do. The system won't suspend until all the processors hit the kernel idle loop and the next_timer_interrupt_critical() returns nothing. At which point an application in a busy loop cripples you. I think we could implement your suggestion more easily by just giving untrusted applications an effectively infinite amount of timer slack, but it still doesn't handle the case where an app behaves excrutiatingly badly. -- Matthew Garrett | mj...@srcf.ucam.org -- 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] [PATCH 0/8] Suspend block api (version 6)
* Matthew Garrett m...@redhat.com [100513 13:03]: On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote: The system stays running because there's something to do. The system won't suspend until all the processors hit the kernel idle loop and the next_timer_interrupt_critical() returns nothing. At which point an application in a busy loop cripples you. Maybe you could deal with the misbehaving untrusted apps in the userspace by sending kill -STOP to them when the screen blanks? Then continue when some event wakes up the system again. I think we could implement your suggestion more easily by just giving untrusted applications an effectively infinite amount of timer slack, but it still doesn't handle the case where an app behaves excrutiatingly badly. Hmm, if you use timer slack then you still need to search through the whole timer list instead of a smaller critical timer list. Both ways sound doable though. 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 01:23:20PM -0700, Tony Lindgren wrote: * Matthew Garrett m...@redhat.com [100513 13:03]: On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote: The system stays running because there's something to do. The system won't suspend until all the processors hit the kernel idle loop and the next_timer_interrupt_critical() returns nothing. At which point an application in a busy loop cripples you. Maybe you could deal with the misbehaving untrusted apps in the userspace by sending kill -STOP to them when the screen blanks? Then continue when some event wakes up the system again. And if that's the application that's listening to the network socket that you want to get a wakeup event from? This problem is hard. I'd love there to be an elegant solution based on using the scheduler, but I really don't know what it is. -- Matthew Garrett | mj...@srcf.ucam.org -- 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, 2010-05-13 at 13:23 -0700, Tony Lindgren wrote: * Matthew Garrett m...@redhat.com [100513 13:03]: On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote: The system stays running because there's something to do. The system won't suspend until all the processors hit the kernel idle loop and the next_timer_interrupt_critical() returns nothing. At which point an application in a busy loop cripples you. Maybe you could deal with the misbehaving untrusted apps in the userspace by sending kill -STOP to them when the screen blanks? Then continue when some event wakes up the system again. Couldn't you just use priorities (nice), or cgroups to deal with that? I'm sure there is a way to limit an apps runtime, so the system does go idle sometimes. I think we could implement your suggestion more easily by just giving untrusted applications an effectively infinite amount of timer slack, but it still doesn't handle the case where an app behaves excrutiatingly badly. Hmm, if you use timer slack then you still need to search through the whole timer list instead of a smaller critical timer list. Both ways sound doable though. There are deferrable timers already in Linux.. It seems like it would just be an extension of that. Daniel -- 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] [PATCH 0/8] Suspend block api (version 6)
On Thursday 13 May 2010, Matthew Garrett wrote: On Thu, May 13, 2010 at 12:36:34PM -0700, Daniel Walker wrote: On Thu, 2010-05-13 at 20:11 +0100, Matthew Garrett wrote: See feature-removal-schedule.txt. So far we have no indication that it's going to be replaced, because nobody has actually suggested a working way to do this better. If we had a concrete implementation proposal for that then we'd be in a pretty different position right now. Ok, feature-removal-schedule.txt applies to everything tho. What your saying is that if this interface only last a short time it might take 6 months, if it last for a long time it would take longer. There's no easy way to know that Google is the only user after some amount of time passes. If the interface is there for a long time, it's because we haven't come up with anything better. And if we haven't come up with anything better, the interface deserves to be there. Moreover, the interface is already in use out-of-tree and that usage is actually _growing_, so we have a growing number of out-of-tree drivers that aren't megrgeable for this very reason. I don't see any _realistic_ way of solving this problem other than merging the opportunistic suspend. If anyone sees one, and I mean _realistic_ and _practically_ _feasible_, please tell me. 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] [PATCH 0/8] Suspend block api (version 6)
* Matthew Garrett m...@redhat.com [100513 13:29]: On Thu, May 13, 2010 at 01:23:20PM -0700, Tony Lindgren wrote: * Matthew Garrett m...@redhat.com [100513 13:03]: On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote: The system stays running because there's something to do. The system won't suspend until all the processors hit the kernel idle loop and the next_timer_interrupt_critical() returns nothing. At which point an application in a busy loop cripples you. Maybe you could deal with the misbehaving untrusted apps in the userspace by sending kill -STOP to them when the screen blanks? Then continue when some event wakes up the system again. And if that's the application that's listening to the network socket that you want to get a wakeup event from? This problem is hard. I'd love there to be an elegant solution based on using the scheduler, but I really don't know what it is. Your system should wake up to an interrupt in that case. Then you have the trusted apps running that can decide if the untrusted apps should be continued or not. The key would be to have the basic apps behave and use the critical timers as needed. The advantage is that then you can do all the policy in the userspace and in a custom pm_idle function. 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] [PATCH 0/8] Suspend block api (version 6)
On Thursday 13 May 2010, Tony Lindgren wrote: * Alan Stern st...@rowland.harvard.edu [100513 07:11]: On Wed, 12 May 2010, Paul Walmsley wrote: Hello, Some general comments on the suspend blockers/wakelock/opportunistic suspend v6 patch series, posted here: https://lists.linux-foundation.org/pipermail/linux-pm/2010-April/025146.html The comments below are somewhat telegraphic in the interests of readability - more specific comments to follow in later E-mails. I am indebted to those of us who discussed these issues at LPC last year and ELC this year for several stimulating discussions. There are several general problems with the design of opportunistic suspend and suspend-blocks. 1. The opportunistic suspend code bypasses existing Linux kernel code, such as timers and the scheduler, that indicates when code needs to run, and when the system is idle. Whoa! That's not my understanding at all. As I see it, opportunistic suspend doesn't bypass any code that isn't already bypassed by the existing suspend code. Users can do echo mem /sys/power/state whenever they want, without regard to kernel timers and the scheduler (other than the fact that the user's thread must be running in order to carry out the write, of course). The difference between echo mem /sys/power/state and suspend blocks is that with suspend blocks the system keeps running. Care to elaborate? 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, 2010-05-13 at 23:11 +0200, Rafael J. Wysocki wrote: On Thursday 13 May 2010, Matthew Garrett wrote: On Thu, May 13, 2010 at 12:36:34PM -0700, Daniel Walker wrote: On Thu, 2010-05-13 at 20:11 +0100, Matthew Garrett wrote: See feature-removal-schedule.txt. So far we have no indication that it's going to be replaced, because nobody has actually suggested a working way to do this better. If we had a concrete implementation proposal for that then we'd be in a pretty different position right now. Ok, feature-removal-schedule.txt applies to everything tho. What your saying is that if this interface only last a short time it might take 6 months, if it last for a long time it would take longer. There's no easy way to know that Google is the only user after some amount of time passes. If the interface is there for a long time, it's because we haven't come up with anything better. And if we haven't come up with anything better, the interface deserves to be there. Moreover, the interface is already in use out-of-tree and that usage is actually _growing_, so we have a growing number of out-of-tree drivers that aren't megrgeable for this very reason. Why can't we merge the drivers? Drivers are just drivers, they don't need this to get merged. (They need it to work with Android) Daniel -- 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] [PATCH 0/8] Suspend block api (version 6)
On Thursday 13 May 2010, Matthew Garrett wrote: On Thu, May 13, 2010 at 01:23:20PM -0700, Tony Lindgren wrote: * Matthew Garrett m...@redhat.com [100513 13:03]: On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote: The system stays running because there's something to do. The system won't suspend until all the processors hit the kernel idle loop and the next_timer_interrupt_critical() returns nothing. At which point an application in a busy loop cripples you. Maybe you could deal with the misbehaving untrusted apps in the userspace by sending kill -STOP to them when the screen blanks? Then continue when some event wakes up the system again. And if that's the application that's listening to the network socket that you want to get a wakeup event from? This problem is hard. I'd love there to be an elegant solution based on using the scheduler, but I really don't know what it is. I agree and I don't understand the problem that people have with the opportunistic suspend feature. It solves a practical issue that _at_ _the_ _moment_ cannot be solved differently, while there's a growing number of out-of-tree drivers depending on this framework. We need those drivers in and because we don't have any viable alternative at hand, we have no good reason to reject it. 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 02:10:06PM -0700, Tony Lindgren wrote: * Matthew Garrett m...@redhat.com [100513 13:29]: And if that's the application that's listening to the network socket that you want to get a wakeup event from? This problem is hard. I'd love there to be an elegant solution based on using the scheduler, but I really don't know what it is. Your system should wake up to an interrupt in that case. Then you have the trusted apps running that can decide if the untrusted apps should be continued or not. What race-free mechanism do you use to ensure that? It's very easy to handwave these problems away. It's very difficult to actually write an implementation that works. -- Matthew Garrett | mj...@srcf.ucam.org -- 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] [PATCH 0/8] Suspend block api (version 6)
On Thursday 13 May 2010, Daniel Walker wrote: On Thu, 2010-05-13 at 23:11 +0200, Rafael J. Wysocki wrote: On Thursday 13 May 2010, Matthew Garrett wrote: On Thu, May 13, 2010 at 12:36:34PM -0700, Daniel Walker wrote: On Thu, 2010-05-13 at 20:11 +0100, Matthew Garrett wrote: See feature-removal-schedule.txt. So far we have no indication that it's going to be replaced, because nobody has actually suggested a working way to do this better. If we had a concrete implementation proposal for that then we'd be in a pretty different position right now. Ok, feature-removal-schedule.txt applies to everything tho. What your saying is that if this interface only last a short time it might take 6 months, if it last for a long time it would take longer. There's no easy way to know that Google is the only user after some amount of time passes. If the interface is there for a long time, it's because we haven't come up with anything better. And if we haven't come up with anything better, the interface deserves to be there. Moreover, the interface is already in use out-of-tree and that usage is actually _growing_, so we have a growing number of out-of-tree drivers that aren't megrgeable for this very reason. Why can't we merge the drivers? Drivers are just drivers, they don't need this to get merged. (They need it to work with Android) Because someone would have to remove suspend blockers (or rather wakelocks) from the drivers, test that they work correctly without suspend blockers and submit the modified versions. Going forward, every party responsible for such a driver would have to maintain an out-of-tree version with suspend blockers (or wakelocks) anyway, so the incentive to do that is zero. Practically, as long as the opportunistic suspend is out of tree, there will be a _growing_ number of out-of-tree drivers out there, which is not acceptable in the long run. 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] [PATCH 0/8] Suspend block api (version 6)
* Rafael J. Wysocki r...@sisk.pl [100513 14:16]: On Thursday 13 May 2010, Matthew Garrett wrote: On Thu, May 13, 2010 at 01:23:20PM -0700, Tony Lindgren wrote: * Matthew Garrett m...@redhat.com [100513 13:03]: On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote: The system stays running because there's something to do. The system won't suspend until all the processors hit the kernel idle loop and the next_timer_interrupt_critical() returns nothing. At which point an application in a busy loop cripples you. Maybe you could deal with the misbehaving untrusted apps in the userspace by sending kill -STOP to them when the screen blanks? Then continue when some event wakes up the system again. And if that's the application that's listening to the network socket that you want to get a wakeup event from? This problem is hard. I'd love there to be an elegant solution based on using the scheduler, but I really don't know what it is. I agree and I don't understand the problem that people have with the opportunistic suspend feature. It seems to be picking quite a few comments for one. It solves a practical issue that _at_ _the_ _moment_ cannot be solved differently, while there's a growing number of out-of-tree drivers depending on this framework. We need those drivers in and because we don't have any viable alternative at hand, we have no good reason to reject it. Nothing is preventing merging the drivers can be merged without these calls. 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] [PATCH 0/8] Suspend block api (version 6)
* Rafael J. Wysocki r...@sisk.pl [100513 14:08]: On Thursday 13 May 2010, Tony Lindgren wrote: The difference between echo mem /sys/power/state and suspend blocks is that with suspend blocks the system keeps running. Care to elaborate? The suspend blocks affects the runtime behaviour of the system by categorizing apps into good and bad apps in a weird way. 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, 2010-05-13 at 23:27 +0200, Rafael J. Wysocki wrote: Because someone would have to remove suspend blockers (or rather wakelocks) from the drivers, test that they work correctly without suspend blockers and submit the modified versions. Going forward, every party responsible for such a driver would have to maintain an out-of-tree version with suspend blockers (or wakelocks) anyway, so the incentive to do that is zero. They should work without wakelock since wakelock are optional .. I mean there's nothing in suspend blockers I've seen that indicates it's required for some drivers to work. So it's just a matter of patching out the wakelocks, with no need to re-test anything. You get the driver mainlined, then maintain a small patch to add wakelocks. Not hard at all , with lots of incentive to do so since you don't have to maintain such a large block of code out of tree. Practically, as long as the opportunistic suspend is out of tree, there will be a _growing_ number of out-of-tree drivers out there, which is not acceptable in the long run. I don't see why your saying that. These driver should work with out all of this, which means they can get mainlined right now. Daniel -- 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] [PATCH 0/8] Suspend block api (version 6)
* Matthew Garrett m...@redhat.com [100513 14:16]: On Thu, May 13, 2010 at 02:10:06PM -0700, Tony Lindgren wrote: * Matthew Garrett m...@redhat.com [100513 13:29]: And if that's the application that's listening to the network socket that you want to get a wakeup event from? This problem is hard. I'd love there to be an elegant solution based on using the scheduler, but I really don't know what it is. Your system should wake up to an interrupt in that case. Then you have the trusted apps running that can decide if the untrusted apps should be continued or not. What race-free mechanism do you use to ensure that? It's very easy to handwave these problems away. It's very difficult to actually write an implementation that works. Can you describe where do you see the race now? Your trusted apps should be have in quite a normal way except the system suspends if no critical timers are on the list. For the untrusted apps you assume you can stop them at whatever userspace policy you set. 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, 13 May 2010, Tony Lindgren wrote: * Alan Stern st...@rowland.harvard.edu [100513 07:11]: On Wed, 12 May 2010, Paul Walmsley wrote: Hello, Some general comments on the suspend blockers/wakelock/opportunistic suspend v6 patch series, posted here: https://lists.linux-foundation.org/pipermail/linux-pm/2010-April/025146.html The comments below are somewhat telegraphic in the interests of readability - more specific comments to follow in later E-mails. I am indebted to those of us who discussed these issues at LPC last year and ELC this year for several stimulating discussions. There are several general problems with the design of opportunistic suspend and suspend-blocks. 1. The opportunistic suspend code bypasses existing Linux kernel code, such as timers and the scheduler, that indicates when code needs to run, and when the system is idle. Whoa! That's not my understanding at all. As I see it, opportunistic suspend doesn't bypass any code that isn't already bypassed by the existing suspend code. Users can do echo mem /sys/power/state whenever they want, without regard to kernel timers and the scheduler (other than the fact that the user's thread must be running in order to carry out the write, of course). The difference between echo mem /sys/power/state and suspend blocks is that with suspend blocks the system keeps running. Irrelevant. Paul wasn't talking about the suspend blockers; he was talking about opportunistic suspend. So what's the difference between opportunistic suspend and echo mem /sys/power/state? Especially when suspend blockers aren't being used? And that's why it should be handled by runtime power management instead. Runtime PM is not capable of freezing userspace and shutting down CPUs. More or less by definition -- if it could then it wouldn't be runtime any more, since the processor wouldn't be running. The suspend blocks seems like a hack to spam filter good and bad apps from timer usage point of view. Applications are categorized as good or bad depending if they grab a susped blocker or not. You're referring just to the userspace part of the suspend blocker API. What about the kernel part? I believe categorizing the apps should be instead done with some timer flags or cgroups instead. That would be compatible with using suspend blockers. 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] [PATCH 0/8] Suspend block api (version 6)
* Daniel Walker dwal...@fifo99.com [100513 14:28]: On Thu, 2010-05-13 at 23:27 +0200, Rafael J. Wysocki wrote: Because someone would have to remove suspend blockers (or rather wakelocks) from the drivers, test that they work correctly without suspend blockers and submit the modified versions. Going forward, every party responsible for such a driver would have to maintain an out-of-tree version with suspend blockers (or wakelocks) anyway, so the incentive to do that is zero. They should work without wakelock since wakelock are optional .. I mean there's nothing in suspend blockers I've seen that indicates it's required for some drivers to work. So it's just a matter of patching out the wakelocks, with no need to re-test anything. You get the driver mainlined, then maintain a small patch to add wakelocks. Not hard at all , with lots of incentive to do so since you don't have to maintain such a large block of code out of tree. Practically, as long as the opportunistic suspend is out of tree, there will be a _growing_ number of out-of-tree drivers out there, which is not acceptable in the long run. I don't see why your saying that. These driver should work with out all of this, which means they can get mainlined right now. I agree with Daniel here. We should keep merging the drivers separate from the suspend blocks issues. 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, 13 May 2010, Tony Lindgren wrote: Well this is an interesting problem, and once solved will be handy for all kind of things. My worry is that if it's integrated in it's current form it will be totally out of control all over the place :( Still hoping we can come up with some clean way that avoid the patching all over the place part.. How about the following, can you please check if it would help with your example of guaranteed handling of event: 1. In the kernel, we add one more timer queue for critical timers. The current timer queue(s) stay as it is. 2. We allow selecting the timer based on some flag, the default behaviour being the current default timer queue. 3. Then we add next_timer_interupt_critical() to only query the critical timers along the lines of the current next_timer_interrupt(). 4. We implement a custom pm_idle that suspends the system based on some logic and checking if next_timer_interrupt_critical() is empty. If the next_timer_interrupt_critical() does not return anything, we assume it's OK to suspend the system. Now to me it sounds if your the input layer and userspace handle both grab the timers with the critical flags, it should be guaranteed that the events get handled before the system is suspended. Why do you want this to be tied to timers? Many of the events in question are asynchronous with no specific timing relations. 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 02:33:29PM -0700, Daniel Walker wrote: On Thu, 2010-05-13 at 23:27 +0200, Rafael J. Wysocki wrote: Because someone would have to remove suspend blockers (or rather wakelocks) from the drivers, test that they work correctly without suspend blockers and submit the modified versions. Going forward, every party responsible for such a driver would have to maintain an out-of-tree version with suspend blockers (or wakelocks) anyway, so the incentive to do that is zero. They should work without wakelock since wakelock are optional .. I mean there's nothing in suspend blockers I've seen that indicates it's required for some drivers to work. So it's just a matter of patching out the wakelocks, with no need to re-test anything. You get the driver mainlined, then maintain a small patch to add wakelocks. Not hard at all , with lots of incentive to do so since you don't have to maintain such a large block of code out of tree. Sorry, but it doesn't seem to work that way. Look at the large number of out-of-tree android device drivers that remain sitting there because of the lack of this interface being in the kernel. Also note that such a driver, without wakelocks, would never get tested, and so, things start quickly diverging. thanks, greg k-h -- 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] [PATCH 0/8] Suspend block api (version 6)
* Alan Stern st...@rowland.harvard.edu [100513 14:32]: On Thu, 13 May 2010, Tony Lindgren wrote: The difference between echo mem /sys/power/state and suspend blocks is that with suspend blocks the system keeps running. Irrelevant. Paul wasn't talking about the suspend blockers; he was talking about opportunistic suspend. So what's the difference between opportunistic suspend and echo mem /sys/power/state? Especially when suspend blockers aren't being used? Opportunistic suspend is really trying to do runtime PM, see below. And that's why it should be handled by runtime power management instead. Runtime PM is not capable of freezing userspace and shutting down CPUs. More or less by definition -- if it could then it wouldn't be runtime any more, since the processor wouldn't be running. Not true. We are already powering off CPUs and rebooting them for at least omaps in every idle loop using cpuidle. The memory stays on. The suspend blocks seems like a hack to spam filter good and bad apps from timer usage point of view. Applications are categorized as good or bad depending if they grab a susped blocker or not. You're referring just to the userspace part of the suspend blocker API. What about the kernel part? IMHO some timer flags should be used in the kernel too. Currently there's no way of knowing which timers are good or bad from suspend point of view. 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] [PATCH 0/8] Suspend block api (version 6)
On Thursday 13 May 2010, Tony Lindgren wrote: * Daniel Walker dwal...@fifo99.com [100513 14:28]: On Thu, 2010-05-13 at 23:27 +0200, Rafael J. Wysocki wrote: Because someone would have to remove suspend blockers (or rather wakelocks) from the drivers, test that they work correctly without suspend blockers and submit the modified versions. Going forward, every party responsible for such a driver would have to maintain an out-of-tree version with suspend blockers (or wakelocks) anyway, so the incentive to do that is zero. They should work without wakelock since wakelock are optional .. I mean there's nothing in suspend blockers I've seen that indicates it's required for some drivers to work. So it's just a matter of patching out the wakelocks, with no need to re-test anything. You get the driver mainlined, then maintain a small patch to add wakelocks. Not hard at all , with lots of incentive to do so since you don't have to maintain such a large block of code out of tree. Practically, as long as the opportunistic suspend is out of tree, there will be a _growing_ number of out-of-tree drivers out there, which is not acceptable in the long run. I don't see why your saying that. These driver should work with out all of this, which means they can get mainlined right now. I agree with Daniel here. We should keep merging the drivers separate from the suspend blocks issues. Unfortunately, that's completely unrealistic. Please refer to the Greg's reply for details. 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] [PATCH 0/8] Suspend block api (version 6)
* Alan Stern st...@rowland.harvard.edu [100513 14:36]: On Thu, 13 May 2010, Tony Lindgren wrote: Well this is an interesting problem, and once solved will be handy for all kind of things. My worry is that if it's integrated in it's current form it will be totally out of control all over the place :( Still hoping we can come up with some clean way that avoid the patching all over the place part.. How about the following, can you please check if it would help with your example of guaranteed handling of event: 1. In the kernel, we add one more timer queue for critical timers. The current timer queue(s) stay as it is. 2. We allow selecting the timer based on some flag, the default behaviour being the current default timer queue. 3. Then we add next_timer_interupt_critical() to only query the critical timers along the lines of the current next_timer_interrupt(). 4. We implement a custom pm_idle that suspends the system based on some logic and checking if next_timer_interrupt_critical() is empty. If the next_timer_interrupt_critical() does not return anything, we assume it's OK to suspend the system. Now to me it sounds if your the input layer and userspace handle both grab the timers with the critical flags, it should be guaranteed that the events get handled before the system is suspended. Why do you want this to be tied to timers? Many of the events in question are asynchronous with no specific timing relations. To me it seems that the non-timer related events can be dealt with toggling the opportunistic suspend idle flag in sysfs. That should depend on the device and use specific policy. 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] [PATCH 0/8] Suspend block api (version 6)
On Thursday 13 May 2010, Tony Lindgren wrote: * Rafael J. Wysocki r...@sisk.pl [100513 14:16]: On Thursday 13 May 2010, Matthew Garrett wrote: On Thu, May 13, 2010 at 01:23:20PM -0700, Tony Lindgren wrote: * Matthew Garrett m...@redhat.com [100513 13:03]: On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote: The system stays running because there's something to do. The system won't suspend until all the processors hit the kernel idle loop and the next_timer_interrupt_critical() returns nothing. At which point an application in a busy loop cripples you. Maybe you could deal with the misbehaving untrusted apps in the userspace by sending kill -STOP to them when the screen blanks? Then continue when some event wakes up the system again. And if that's the application that's listening to the network socket that you want to get a wakeup event from? This problem is hard. I'd love there to be an elegant solution based on using the scheduler, but I really don't know what it is. I agree and I don't understand the problem that people have with the opportunistic suspend feature. It seems to be picking quite a few comments for one. It solves a practical issue that _at_ _the_ _moment_ cannot be solved differently, while there's a growing number of out-of-tree drivers depending on this framework. We need those drivers in and because we don't have any viable alternative at hand, we have no good reason to reject it. Nothing is preventing merging the drivers can be merged without these calls. And yet, there _is_ a growing nuber of drivers that don't get merge because of that. That's _reality_. Are you going to discuss with facts, or what? 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] [PATCH 0/8] Suspend block api (version 6)
On Thursday 13 May 2010, Tony Lindgren wrote: * Rafael J. Wysocki r...@sisk.pl [100513 14:08]: On Thursday 13 May 2010, Tony Lindgren wrote: The difference between echo mem /sys/power/state and suspend blocks is that with suspend blocks the system keeps running. Care to elaborate? The suspend blocks affects the runtime behaviour of the system by categorizing apps into good and bad apps in a weird way. I don't see this, can you please explain? 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, 13 May 2010, Tony Lindgren wrote: And that's why it should be handled by runtime power management instead. Runtime PM is not capable of freezing userspace and shutting down CPUs. More or less by definition -- if it could then it wouldn't be runtime any more, since the processor wouldn't be running. Not true. We are already powering off CPUs and rebooting them for at least omaps in every idle loop using cpuidle. The memory stays on. Okay, that's a valid point. But is that approach usable in general (i.e., on non-OMAP systems)? How do you handle situations where the CPU is currently idle but an event (such as I/O completion) is expected to occur in the near future? You don't want to power-off and reboot then, do you? 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] [PATCH 0/8] Suspend block api (version 6)
On Thursday 13 May 2010, Tony Lindgren wrote: * Alan Stern st...@rowland.harvard.edu [100513 14:32]: On Thu, 13 May 2010, Tony Lindgren wrote: The difference between echo mem /sys/power/state and suspend blocks is that with suspend blocks the system keeps running. Irrelevant. Paul wasn't talking about the suspend blockers; he was talking about opportunistic suspend. So what's the difference between opportunistic suspend and echo mem /sys/power/state? Especially when suspend blockers aren't being used? Opportunistic suspend is really trying to do runtime PM, see below. NO, IT IS NOT! What it does is to detect situations in which it is desirable to put the _entire_ _system_ to sleep, while runtime PM works on a per-device basis. And that's why it should be handled by runtime power management instead. Runtime PM is not capable of freezing userspace and shutting down CPUs. More or less by definition -- if it could then it wouldn't be runtime any more, since the processor wouldn't be running. Not true. We are already powering off CPUs and rebooting them for at least omaps in every idle loop using cpuidle. The memory stays on. What about user space, though? Do you freeze it? The suspend blocks seems like a hack to spam filter good and bad apps from timer usage point of view. Applications are categorized as good or bad depending if they grab a susped blocker or not. You're referring just to the userspace part of the suspend blocker API. What about the kernel part? IMHO some timer flags should be used in the kernel too. Currently there's no way of knowing which timers are good or bad from suspend point of view. How is that answering the Alan's question? 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] [PATCH 0/8] Suspend block api (version 6)
On Thursday 13 May 2010, Tony Lindgren wrote: * Alan Stern st...@rowland.harvard.edu [100513 14:36]: On Thu, 13 May 2010, Tony Lindgren wrote: Well this is an interesting problem, and once solved will be handy for all kind of things. My worry is that if it's integrated in it's current form it will be totally out of control all over the place :( Still hoping we can come up with some clean way that avoid the patching all over the place part.. How about the following, can you please check if it would help with your example of guaranteed handling of event: 1. In the kernel, we add one more timer queue for critical timers. The current timer queue(s) stay as it is. 2. We allow selecting the timer based on some flag, the default behaviour being the current default timer queue. 3. Then we add next_timer_interupt_critical() to only query the critical timers along the lines of the current next_timer_interrupt(). 4. We implement a custom pm_idle that suspends the system based on some logic and checking if next_timer_interrupt_critical() is empty. If the next_timer_interrupt_critical() does not return anything, we assume it's OK to suspend the system. Now to me it sounds if your the input layer and userspace handle both grab the timers with the critical flags, it should be guaranteed that the events get handled before the system is suspended. Why do you want this to be tied to timers? Many of the events in question are asynchronous with no specific timing relations. To me it seems that the non-timer related events can be dealt with toggling the opportunistic suspend idle flag in sysfs. That should depend on the device and use specific policy. OK, that's all hand waving. Do you have any patches, please? 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 02:25:56PM -0700, Tony Lindgren wrote: I agree and I don't understand the problem that people have with the opportunistic suspend feature. It seems to be picking quite a few comments for one. It's picking up a lot of comments because *someone* seems to be trying to use a last post wins style of argumentation. One of the things that is hard for people who aren't regular denizens of LKML is to understand whose comments can be ignored. Seriously, you are posting a lot, but it's not clear you're making any clear sense... - Ted -- 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 12:42 PM, Tony Lindgren t...@atomide.com wrote: * Matthew Garrett m...@redhat.com [100513 12:20]: On Thu, May 13, 2010 at 12:17:17PM -0700, Tony Lindgren wrote: The suspend blocks seems like a hack to spam filter good and bad apps from timer usage point of view. Applications are categorized as good or bad depending if they grab a susped blocker or not. I believe categorizing the apps should be instead done with some timer flags or cgroups instead. I agree, but we have no mechanism for implementing that in a race-free way. We don't even have a realistical proposal for what that mechanism would look like. Should we refuse bread today for the promise of cake tomorrow? Well this is an interesting problem, and once solved will be handy for all kind of things. My worry is that if it's integrated in it's current form it will be totally out of control all over the place :( Still hoping we can come up with some clean way that avoid the patching all over the place part.. How about the following, can you please check if it would help with your example of guaranteed handling of event: 1. In the kernel, we add one more timer queue for critical timers. The current timer queue(s) stay as it is. 2. We allow selecting the timer based on some flag, the default behaviour being the current default timer queue. 3. Then we add next_timer_interupt_critical() to only query the critical timers along the lines of the current next_timer_interrupt(). 4. We implement a custom pm_idle that suspends the system based on some logic and checking if next_timer_interrupt_critical() is empty. If the next_timer_interrupt_critical() does not return anything, we assume it's OK to suspend the system. I think trying to solve this at the timer level requires more patching than using suspend blockers. With suspend blocker you block suspend until some work has finished, or an event has been consumed. You can safely use any existing synchronous api. Now to me it sounds if your the input layer and userspace handle both grab the timers with the critical flags, it should be guaranteed that the events get handled before the system is suspended. There are no timers used in this path. However any critical section used from this path could cause the system to enter idle. Instead of blocking suspend while there are unprocessed input event you now have to make sure all code that can block any of the threads involved in processing those event don't wait on a non critical timer. -- 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] [PATCH 0/8] Suspend block api (version 6)
On Friday 14 May 2010, Tony Lindgren wrote: * Alan Stern st...@rowland.harvard.edu [100513 14:56]: On Thu, 13 May 2010, Tony Lindgren wrote: And that's why it should be handled by runtime power management instead. Runtime PM is not capable of freezing userspace and shutting down CPUs. More or less by definition -- if it could then it wouldn't be runtime any more, since the processor wouldn't be running. Not true. We are already powering off CPUs and rebooting them for at least omaps in every idle loop using cpuidle. The memory stays on. Okay, that's a valid point. But is that approach usable in general (i.e., on non-OMAP systems)? Yes if your system wakes to interrupts at least. If your system does not wake to timer events, then you'll get missed timers. So it should work on PC too with CONFIG_NO_HZ and if RTC was used for the timer wake event. How do you handle situations where the CPU is currently idle but an event (such as I/O completion) is expected to occur in the near future? You don't want to power-off and reboot then, do you? The idle code looks at next_timer_interrupt() value, then if the next timer event if far enough ahead, the system powers down and wakes to the timer interrupt. It also wakes to device interrupts. For the record, waking to interrupts doesn't work on quite some systems (like ACPI-based PCs for one example). 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 02:46:53PM -0700, Greg KH wrote: On Thu, May 13, 2010 at 02:33:29PM -0700, Daniel Walker wrote: You get the driver mainlined, then maintain a small patch to add wakelocks. Not hard at all , with lots of incentive to do so since you don't have to maintain such a large block of code out of tree. Sorry, but it doesn't seem to work that way. Look at the large number of out-of-tree android device drivers that remain sitting there because of the lack of this interface being in the kernel. Is that really the issue? The ones I've looked at have mostly suffered from being built on 2.6.29 and needing refreshes for current kernel APIs or from general code quality issues - I don't recall ever looking at one and thinking that the wakelocks were the one issue. Also note that such a driver, without wakelocks, would never get tested, and so, things start quickly diverging. Chances are that if the driver is useful people will start using it in non-Android systems anyway. As people have already observed wakelocks needn't have any practical effect on the running system so if the drivers are broken without wakelocks they'd be broken anyway. If this really is a big concern with getting drivers into mainline then surely we could just add some noop wakelock functions for the drivers to call? It's not particularly pretty but it'd deal with the driver merge side of things. -- 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] [PATCH 0/8] Suspend block api (version 6)
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Greg KH Sent: Thursday, May 13, 2010 4:47 PM Also note that such a driver, without wakelocks, would never get tested, and so, things start quickly diverging. Do wakelock enabled drivers require a wakelock aware user space to function properly? If the driver is added you want to make sure the benefit is there and testable for all userspaces. Early Android service managers did take/release userspace locks to ensure the handoff worked. Getting all these drivers is positive. Getting to some constraint mechanism is positive. It does need to exist end to end to make a difference at the battery. Regards, Richard W. -- 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] [PATCH 0/8] Suspend block api (version 6)
On Friday 14 May 2010, Mark Brown wrote: On Thu, May 13, 2010 at 02:46:53PM -0700, Greg KH wrote: On Thu, May 13, 2010 at 02:33:29PM -0700, Daniel Walker wrote: You get the driver mainlined, then maintain a small patch to add wakelocks. Not hard at all , with lots of incentive to do so since you don't have to maintain such a large block of code out of tree. Sorry, but it doesn't seem to work that way. Look at the large number of out-of-tree android device drivers that remain sitting there because of the lack of this interface being in the kernel. Is that really the issue? The ones I've looked at have mostly suffered from being built on 2.6.29 and needing refreshes for current kernel APIs or from general code quality issues - I don't recall ever looking at one and thinking that the wakelocks were the one issue. Also note that such a driver, without wakelocks, would never get tested, and so, things start quickly diverging. Chances are that if the driver is useful people will start using it in non-Android systems anyway. You're missing the point IMO. Even if they are only used on Android, there still is a problem if they don't go into the mainline, because that leads to code divergence that's growing over time and will ultimately create an entire ecosystem that's independent of the mainline. We've been successful in avoiding that for quite some time and I don't think we should allow that to happen right now because of the opportunistic suspend feature. I'm not a big fan of suspend blockers myself, but let's face it, _currently_ there's no alternative and we need to stop the trend, the sooner the better. As people have already observed wakelocks needn't have any practical effect on the running system so if the drivers are broken without wakelocks they'd be broken anyway. You need to prove the reverse, ie. that a driver working correctly with wakelocks will also work correctly without them, which is not a given. If this really is a big concern with getting drivers into mainline then surely we could just add some noop wakelock functions for the drivers to call? Well, I don't see a big difference between that and adding the feature depending on a .config option. Really. It's not particularly pretty but it'd deal with the driver merge side of things. Again, I don't see why you hate that feature so much. What is there to worry about? 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 11:27:49PM +0100, Mark Brown wrote: On Thu, May 13, 2010 at 02:46:53PM -0700, Greg KH wrote: On Thu, May 13, 2010 at 02:33:29PM -0700, Daniel Walker wrote: You get the driver mainlined, then maintain a small patch to add wakelocks. Not hard at all , with lots of incentive to do so since you don't have to maintain such a large block of code out of tree. Sorry, but it doesn't seem to work that way. Look at the large number of out-of-tree android device drivers that remain sitting there because of the lack of this interface being in the kernel. Is that really the issue? The ones I've looked at have mostly suffered from being built on 2.6.29 and needing refreshes for current kernel APIs or from general code quality issues - I don't recall ever looking at one and thinking that the wakelocks were the one issue. Yes, it is an issue. See the mess that we have had in trying to get some of the original G1 drivers merged in the staging tree for proof of this. Also note that such a driver, without wakelocks, would never get tested, and so, things start quickly diverging. Chances are that if the driver is useful people will start using it in non-Android systems anyway. No, not usually. Do you really think that someone else is going to use the G1 camera driver for anything else? :) As people have already observed wakelocks needn't have any practical effect on the running system so if the drivers are broken without wakelocks they'd be broken anyway. If this really is a big concern with getting drivers into mainline then surely we could just add some noop wakelock functions for the drivers to call? It's not particularly pretty but it'd deal with the driver merge side of things. I fail to see why getting the real functionality of the wakelocks into the kernel is a problem. Especially as they fit a real need, and work well for that. thanks, greg k-h -- 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] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 05:33:58PM -0500, Woodruff, Richard wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Greg KH Sent: Thursday, May 13, 2010 4:47 PM Also note that such a driver, without wakelocks, would never get tested, and so, things start quickly diverging. Do wakelock enabled drivers require a wakelock aware user space to function properly? Not that I can tell, but others might know more. If the driver is added you want to make sure the benefit is there and testable for all userspaces. Agreed. thanks, greg k-h -- 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
