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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
