[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: Felipe Balbi on 17 May 2010 14:20 Hi, On Mon, May 17, 2010 at 06:58:20PM +0100, Matthew Garrett wrote: > 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. don't get me wrong, I have faced similar problems of use time targets due to ill-behaved applications, we just decided to deal with it with the help of bugzilla. File a bug to that application and get the developer to fix it. At least you are teaching the guy to fish. I understand when you open an AppStore the problem grows bigger but, like I replied to James, build an automated system to check average power usage on the SDK and AppStore acceptance process and you get developers to fix their apps before they reach the device. -- 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: Felipe Balbi on 17 May 2010 14:20 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-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: Brian Swetland on 17 May 2010 14:30 On Mon, May 17, 2010 at 11:12 AM, Felipe Balbi <me(a)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-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 14:40 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-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: Mark Brown on 17 May 2010 14:50
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-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/ |