[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 17:10 On Mon, May 17, 2010 at 1:17 PM, Vitaly Wool <vitalywool(a)gmail.com> wrote: > 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. >>> Okay, I measured with and without using the scientific method. With a 1390mAh battery, if you set your device in airplane mode you will get 435.7 hours of standby vs 397.14 hours of standby. Is this data sufficient for a "different discussion" now? >>> 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? > Network configuration and cell reception is a big factor here. You can easily get +4-8mA on the original numbers I gave below, so its large enough to skew your "perceived" power usage. >> 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. > The important part here is not the absolute value, but how they compare relatively. If I added off-mode support then I the averages would both drop, but they would not be the same (key point). I simply wanted show with real numbers that there is a difference in opportunistic suspend and without. Instead of purely hypothesizing that there is no power benefit from using opportunistic suspend. >> 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. > I admit, our timeout approach is a bit hacky, but there is method for the madness. In order to properly determine when you should turn off wifi for "perfect" power management, you need to know a few things. 1) When, in the 'future' is the user going to turn on the screen. 2) How many network packets will be sent to the device while the screen is off. Some of these factors are Android specific, in particular the device always has a TCP connection open to google servers. So switching from WIFI -> 3G for example causes us to generate extra network traffic as we try to establish our SSL connection to google servers. Likewise this cost is paid when moving from 3G -> wifi. Its *really* hard to predict the future, so we use this timeout based off of various heuristics, usability studies and power measurements. So we attempt to minimize excessive network io for both power reasons and network reasons (ie: cell carriers), as well as user experience (latency to connect / disconnect to a wifi access point). However we are not talking about kernel power management here, we are talking about Android policy that might be dedicated by various OEM / carrier requirements and user experience. I wouldn't necessarily go so far and say its flat out "wrong" what we are doing, but I do feel that it is Android specific enough that having our own policy for this is valid. If you feel strongly against this, I will be more than happy to dive into details in an android specific thread off lkml. -- Mike > 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: Kevin Hilman on 17 May 2010 19:00 Mike Chan <mike(a)android.com> writes: > 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. Agreed. I was reluctant to even make the comparison for all those reasons, but with the lack of real numbers, it was all I had to show a very rough subjective guess, and at least show that with and without opportunistic suspend, you're in the same ballpark. >>> 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. Excellent. Thanks for some real numbers. (btw, sure would be nice to have the basic droid board files in mainline. ;) > 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). [at risk of stating the obvious] Since both approaches hit the same power states, if the system was truly idle, you'd expect the numbers to be the same, right? So what the difference shows is that the system is not fully idle, IOW userspace and/or kernel wakeups are cusing the difference. It might also be instructive to see these numbers with a "noop" userspace, like just booting into busybox init=/bin/sh (or the android equivalent.) That would show how much of that difference is due to kernel idleness (or lack thereof.) Even still, to me this all boils down to the lack of definition of the problem and clear description of the solution The fundamental problem is one of idleness. What we want is the system to be idle in order to hit the lowest power states. We can't get there because the system is not truly idle. So, there are basically two solutions: 1) find and fix the problem spots so we can be idle more often 2) add a new definition of idle so we can be idle more often Opporuntistic suspend takes the second approach where the new definition of idle is "no suspend blockers held." Of course, I clearly prefer the former, but it's also becoming clear that since I'm the only one still whining about it, I must be too much of an idealist to keep hoping for it. 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: Brian Swetland on 17 May 2010 19:10 On Mon, May 17, 2010 at 3:55 PM, Kevin Hilman <khilman(a)deeprootsystems.com> wrote: > > The fundamental problem is one of idleness. What we want is the > system to be idle in order to hit the lowest power states. We can't > get there because the system is not truly idle. > > So, there are basically two solutions: > > 1) find and fix the problem spots so we can be idle more often > 2) add a new definition of idle so we can be idle more often > > Opporuntistic suspend takes the second approach where the new > definition of idle is "no suspend blockers held." > > Of course, I clearly prefer the former, but it's also becoming clear > that since I'm the only one still whining about it, I must be too much > of an idealist to keep hoping for it. I'd love to see the former work, but it is not something that I think is going to be fixed rapidly. It potentially involves many different subsystems, and still requires some need for managing arbitrary userspace agents which may have non-ideal behaviors (if we're going to solve the problem for general purpose devices that can run arbitrary user-installed software). Incremental improvements are great though (for example, that we can now be in lowest power idle for periods greater than 2 seconds due to the change in .32). Even when operating in opportunistic suspend, it is still advantageous for idle to be as idle as possible and we should keep working toward that goal. If we get to the point where the power difference between suspend-in-idle and opportunistic suspend is zero, then we no longer need the latter. I don't think anybody on the Google/Android side is arguing that we *shouldn't* pursue dynamic pm and overall making idle more idle more of the time. We're just saying that here and now we are not at the ideal and opportunistic suspend gains us real power savings and 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 18 May 2010 03:10 On Mon, May 17, 2010 at 09:49:35PM +0200, ext James Bottomley wrote: >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 ... what does this add to suspend_blockers discussion ? -- balbi DefectiveByDesign.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: James Bottomley on 18 May 2010 10:10
On Tue, 2010-05-18 at 09:40 +0300, Felipe Balbi wrote: > On Mon, May 17, 2010 at 09:49:35PM +0200, ext James Bottomley wrote: > >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 ... > > what does this add to suspend_blockers discussion ? Sorry I was evidently being too subtle. The point is that if, as you acknowledge, that you can't train firmware engineers to be responsive, there's no reason to think you can train software engineers in the same quality ... they're very similar people. The corollary is that real world systems have to operate in the face of misbehaving hardware *and* software. 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/ |