[PATCH 0/8] Suspend block api (version 6)
in [Kernel]
|
Prev: [PATCH 8/8] power_supply: Block suspend while power supply change notifications are pending
Next: [PATCH 7/8] Input: Block suspend while event queue is not empty.
From: James Bottomley on 17 May 2010 13:10 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-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Felipe Balbi on 17 May 2010 13:50 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-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 17 May 2010 14:00 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 | mjg59(a)srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Daniel Walker on 17 May 2010 14:00 On Mon, 2010-05-17 at 13:04 -0400, James Bottomley wrote: > 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. If you have an idle based PM system you could get the same information from having scheduler statistics. Since the "bad" apps are the ones that are always either running or ready to run, and they would hardly ever sleep. I don't know if there are specific scheduler statistics for that, but it doesn't seem like it would be hard to make. It's even much more natural than getting statistics from suspend blockers, since it requires the app to be custom made to use suspend blockers. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: James Bottomley on 17 May 2010 14:10
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-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |