[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: Mike Chan on 17 May 2010 14:50 On Mon, May 17, 2010 at 11:39 AM, Felipe Balbi <me(a)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 majordomo(a)vger.kernel.org > More majordomo info at �http://vger.kernel.org/majordomo-info.html > -- 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:50 On Mon, May 17, 2010 at 11:39 AM, Felipe Balbi <me(a)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-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: Kevin Hilman on 17 May 2010 15:00 James Bottomley <James.Bottomley(a)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-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 15:30 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-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 15:40
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-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/ |