suspend blockers & Android integration
in [Kernel]
|
Prev: How do I ignore the changes made by CVS keyword substitution efficiently?
Next: [PATCH 1/2] x86: make save_stack_address() !CONFIG_FRAME_POINTER friendly
From: david on 6 Jun 2010 04:30 On Thu, 3 Jun 2010, Linus Torvalds wrote: > On Thu, 3 Jun 2010, Linus Torvalds wrote: >> >> so I'd like to see the opportunistc suspend thing think about CPU >> offlining > > Side note: one reason for me being somewhat interested in the CPU > offlining is that I think the Android kind of opportunistic suspend is > _not_ likely something I'd like to see on a desktop. But an the > "opportunistic CPU offliner"? That might _well_ be useful even outside of > any other suspend activity. When the OLPC was first released there was talk that the hardware was well designed for sleeping (including the ability for the display to keep going even if the system itself shut down), with the idealistic talk of the system possibly sleeping between keystrokes. things didn't end up working (a couple pieces of hardware ended up not playing well with others), but the concept is still something that could end up impacting users outside of the mobile phone market, even if not on your traditional desktop. David Lang -- 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 6 Jun 2010 04:40 On Sun, Jun 6, 2010 at 10:20 AM, Brian Swetland <swetland(a)google.com> wrote: > On Sun, Jun 6, 2010 at 12:52 AM, Vitaly Wool <vitalywool(a)gmail.com> wrote: >> 2010/6/5 Arve Hj�nnev�g <arve(a)android.com>: >>> >>> We clearly have different standards for what we consider good. We >>> measure time suspended in minutes or hours, not seconds, and waking up >>> every second or two causes a noticeable decrease in battery life on >>> the hardware we have today. >> >> Are you stating that the existing Android implementation enters the >> suspended state for hours for any of the existing designs? > > It varies depending on device and usage. �The battery monitoring on > NexusOne happens every ten minutes, so that's the longest you'll see a > N1 suspended for. �On a G1 or Dream/myTouch you can see 20-30 minutes > between wakeups (depending on network issues and background data sync > traffic), and if you have background data sync off those devices can > sit in suspend for days at a time (unless you receive a phone call or > something). �In "airplane mode", with no local alarms, a device can > easily sit in the lowest power state for a month or so, until the > battery finally runs out. That only concerns the case when you have just turned on the phone and left it laying around. You have to admit that it's not the common case for a smartphone. The common case is that you've played with it for a bit, turning on things like BT/WIFI, running some apps and so on. And doing so you'll end up having wake locks taken from everywhere, so I can hardly see a second of suspend for Nexus. E. g. when the wireless is connected to an AP, it takes a wake lock which is released on 15 minutes touchscreen inactivity timeout, as far as I can tell. So: * the system will never hit suspend during this period; * if the download was ongoing and had not been completed during this period, it will be terminated. So the bottom line is: the approach is very inflexible. Of course it can give you the best power savings if you turn the Airplane mode on as soon as you switched on the phone, but this is not what a typical user would do. ~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: Brian Swetland on 6 Jun 2010 05:30 On Sun, Jun 6, 2010 at 1:32 AM, Vitaly Wool <vitalywool(a)gmail.com> wrote: >> >> It varies depending on device and usage. The battery monitoring on >> NexusOne happens every ten minutes, so that's the longest you'll see a >> N1 suspended for. On a G1 or Dream/myTouch you can see 20-30 minutes >> between wakeups (depending on network issues and background data sync >> traffic), and if you have background data sync off those devices can >> sit in suspend for days at a time (unless you receive a phone call or >> something). In "airplane mode", with no local alarms, a device can >> easily sit in the lowest power state for a month or so, until the >> battery finally runs out. > > That only concerns the case when you have just turned on the phone and > left it laying around. > You have to admit that it's not the common case for a smartphone. The > common case is that you've played with it for a bit, turning on things > like BT/WIFI, running some apps and so on. And doing so you'll end up > having wake locks taken from everywhere, so I can hardly see a second > of suspend for Nexus. The common case for a phone is to be sitting around. Even for heavy smartphone users, unless they power on, use the device screen-on for 4 hours solid or whatnot and drain the battery straight away, the device is going to spend a significant portion of its operating time in screen-off standby modes (conserving power for when you take a call, browse the web, etc). For typical users on typical android devices, this means the device stays suspended for 5-10 minutes at a time, coming up for air when a network packet (mail sync, im, etc) or alarm (battery monitor) wakes the device briefly. Obviously with the right combination of bad apps you will see a device suspending more rarely. > E. g. when the wireless is connected to an AP, it takes a wake lock > which is released on 15 minutes touchscreen inactivity timeout, as far > as I can tell. So: > > * the system will never hit suspend during this period; > * if the download was ongoing and had not been completed during this > period, it will be terminated. I'm pretty sure the wifi subsystem does not actually take a wakelock while its connected -- it does have an alarm to spin down wifi after 15 minutes (by default, and user disableable) largely due to power inefficiencies in the wifi solution in some early devices. There's some room for improvement here, obviously. With a decent wifi chipset and implementation, depending on local wifi traffic patterns, you can see power usage competitive to cellular. > So the bottom line is: the approach is very inflexible. Of course it > can give you the best power savings if you turn the Airplane mode on > as soon as you switched on the phone, but this is not what a typical > user would do. The savings in airplane mode (apart from preventing data connections, which saves power by preventing data-hungry background apps from doing much) is the difference between standby with radio (3-5mA) and without (1-2mA). I'm not suggesting that airplane mode is a typical case, just using it as in illustration of the more extreme standby case. Users do like that to work too -- I recall Arve leaving a device in his filing cabinet with the radio off while he was out of the country for three weeks once, and him discovering it was still running with something like 25% battery remaining when he returned. In any case, I'm saying that suspending for minutes at a time (typical, 10s of minutes or more in some cases, hours in others), does happen and it does represent an improvement over suspending or otherwise entering your lowest power state for seconds at a time. 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: david on 6 Jun 2010 06:00 On Sun, 6 Jun 2010, Brian Swetland wrote: > The savings in airplane mode (apart from preventing data connections, > which saves power by preventing data-hungry background apps from doing > much) is the difference between standby with radio (3-5mA) and without > (1-2mA). I'm not suggesting that airplane mode is a typical case, > just using it as in illustration of the more extreme standby case. for the sake of discussion, let's say that standby is 5ma and full operation is 500ma and a minimal wakeup is 0.1 sec. these are probably fairly pessimistic numbers. waking up every second would be awake 10% of the time, so in an hour you would use .9*5mA + .1*500mA = 4.5mA +45mA = 49.5mAH waking up every 10 seconds would be awake 1% of the time, so in an hour you would use .99*5mA + 0.01*500mA = 4.95mA + 5mA = 9.95mAH waking up every 100 seconds would be awake 0.1% of the time, so in an hour you would use .999*5mA + 0.001*500mA =4.995mA + 0.5mA = 5.495mAH waking up every 1000 seconds would be awake 0.01% of the time so in an hour you would use .9999*5mA + 0.0001*500mA = 4.9995mA + 0.05mAH = 5.0495mAH now if you have a 1000mAH battery (small, but reasonable for a smartphone) your standby life would be ..1 second wakeup (on continuously) = 2 hours 1 second wakup = 20 hours 10 second wakeup = 100 hours 100 second wakeup = 182 hours 1000 second wakeup = 198 hours if you could shrink the time awake to 0.01 second per wakeup you would shift this all up a category (and avoiding the need to wake everything up to service a timer would help do this) this effort very definantly has diminishing returns as you go to larger sleep periods as the constant standby power draw becomes more and more dominating. someone mentioned that they were getting the sleep time of normal systems up past the 1 second mark with the 10 second mark looking very attainable. that is where you get the most benifit for whatever changes are needed. getting up to a 2 min sleep time really gives you about all the benifit that you can get, going from there to 15 min makes very little difference. don't let chasing the best possible sleep time prevent you from considering options that would be good enough in time, but would drastically reduce the maintinance effort (as things could be upstreamed more easily), and would be usable on far more systems. David Lang -- 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 6 Jun 2010 06:10
On Sun, Jun 6, 2010 at 11:21 AM, Brian Swetland <swetland(a)google.com> wrote: > > The common case for a phone is to be sitting around. �Even for heavy > smartphone users, unless they power on, use the device screen-on for 4 > hours solid or whatnot and drain the battery straight away, the device > is going to spend a significant portion of its operating time in > screen-off standby modes (conserving power for when you take a call, > browse the web, etc). Sure, but my point was, some non-trivial (still kind of natural for a smartphone) activities with the device will prevent it from suspending for quite some time. Even worse, the suspend wakelock will keep the whole kernel active, as opposed to powering off unused devices separately as it's done in runtime PM. Yep, I know about the "early suspend" type of thing; yet it's excess, not mainlined and lacks granularity. > For typical users on typical android devices, this means the device > stays suspended for 5-10 minutes at a time, coming up for air when a > network packet (mail sync, im, etc) or alarm (battery monitor) wakes > the device briefly. �Obviously with the right combination of bad apps > you will see a device suspending more rarely. Wasn't that you who stated that you so successfully tolerate bad apps with opportunistic suspend that anything of the kind should not really be the case? :) >> E. g. when the wireless is connected to an AP, it takes a wake lock >> which is released on 15 minutes touchscreen inactivity timeout, as far >> as I can tell. So: >> >> * the system will never hit suspend during this period; >> * if the download was ongoing and had not been completed during this >> period, it will be terminated. > > I'm pretty sure the wifi subsystem does not actually take a wakelock > while its connected -- it does have an alarm to spin down wifi after > 15 minutes (by default, and user disableable) largely due to power > inefficiencies in the wifi solution in some early devices. Oh? How does it make sure it's not powered off while scanning for APs, for instance? > Users do like that to work too -- I recall Arve leaving a device in > his filing cabinet with the radio off while he was out of the country > for three weeks once, and him discovering it was still running with > something like 25% battery remaining when he returned. So what you're actually up to is that a user should restart the phone and turn the radio off if he wants to find it running when he's back from a long business trip or something. Nice... > In any case, I'm saying that suspending for minutes at a time > (typical, 10s of minutes or more in some cases, hours in others), does > happen and it does represent an improvement over suspending or > otherwise entering your lowest power state for seconds at a time. That's for sure, if _all_ the other parameters *are* *equal*. This is obviously not the case. ~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/ |