[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 15:40 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-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 16:00 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-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: Mike Chan on 17 May 2010 16:10 On Mon, May 17, 2010 at 12:27 PM, Vitaly Wool <vitalywool(a)gmail.com> wrote: > On Mon, May 17, 2010 at 6:12 PM, Kevin Hilman > <khilman(a)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-pm(a)lists.linux-foundation.org > https://lists.linux-foundation.org/mailman/listinfo/linux-pm > -- 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: Vitaly Wool on 17 May 2010 16:20 On Mon, May 17, 2010 at 10:07 PM, Mike Chan <mike(a)android.com> wrote: > On Mon, May 17, 2010 at 12:27 PM, Vitaly Wool <vitalywool(a)gmail.com> wrote: >> On Mon, May 17, 2010 at 6:12 PM, Kevin Hilman >> <khilman(a)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-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: Rafael J. Wysocki on 17 May 2010 16:30
On Monday 17 May 2010, Brian Swetland wrote: > On Mon, May 17, 2010 at 11:39 AM, Felipe Balbi <me(a)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-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/ |