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: Thomas Gleixner on 6 Jun 2010 06:10 On Sat, 5 Jun 2010, Arve Hj�nnev�g wrote: > 2010/6/5 Thomas Gleixner <tglx(a)linutronix.de>: > > On Sat, 5 Jun 2010, Arve Hj�nnev�g wrote: > >> That is too simple. You also have to prevent A from being frozen while > >> it is processing the event or the result would be the same as if it > >> was frozen beforehand. > > > > The framework decides when to freeze the app in the first place (as > > your framework does now when it decides to suspend) > > > > � � So it knows whether the app is frozen or not. > > > > � � So it knows damend well whether it processed the event or not. > > > > Our user-space code is not single-threaded. So just because an app was > not frozen when you checked does not mean it will remain unfrozen. We > can use the same user-space wakelock api we have now to prevent > freezing apps instead of preventing suspend, but we loose any > advantage we get from freezing just a subset of processes this way. Errm. That does not matter whether its single threaded or not. And right, you have to prevent that it gets frozen while you are calling into it. But that does not change the fact that you can do finer grained power control even in the case when suspend is impossible because a background application has work to finish and does that without requiring interaction with the frozen part. That's what I pointed out in the first place and you just argue in circles why it is impossible to do so. Let me recapitulate: Full on state: No difference because everything runs Full suspend state: No difference because everything is down Screen off, background work active: Suspend blocker held by the active background work lets other applications which are unrelated consume CPU cycles and power. versus Frozen apps restrict the CPU cycles and power consumption to the background work (if there are no interactions with frozen tasks) and therefor save more power than the on/off approach. If your user space stack cannot be distangled that way, then it's a problem of your user space stack and not changing the fact, that a well designedd system allows you to do that. Any objections ? Thanks, tglx
From: Vitaly Wool on 6 Jun 2010 06:20 2010/6/6 <david(a)lang.hm>: > as an example (taken from this thread). > > system A needs to wake up to get a battery reading, store it and go back to > sleep, It does so every 10 seconds. But when it does so it only runs the one > process and then goes back to sleep. > > system B has the same need, but wakes up every 10 minutes. but when it does > so it fully wakes up and this allows the mail app to power up the radio, > connect to the Internet and start checking for new mail before oppurtunistic > sleep shuts things down (causing the mail check to fail) > > System A will last considerably longer on a battery than System B. Exactly, thanks for pointing out the specific example :) ~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: david on 6 Jun 2010 06:20 On Sun, 6 Jun 2010, Vitaly Wool wrote: > On Sun, Jun 6, 2010 at 11:21 AM, Brian Swetland <swetland(a)google.com> wrote: >> 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. and while it will represent an improvement, is the cost worth the relativly minor benifit that going from 10s of seconds of sleep to 10s of minuites of sleep give you? a system that wakes up every 10 seconds, but only wakes the portion of the system needed for the wakeup can easily outlast one that wakes up far less frequently, but when it's awake is fully awake. as an example (taken from this thread). system A needs to wake up to get a battery reading, store it and go back to sleep, It does so every 10 seconds. But when it does so it only runs the one process and then goes back to sleep. system B has the same need, but wakes up every 10 minutes. but when it does so it fully wakes up and this allows the mail app to power up the radio, connect to the Internet and start checking for new mail before oppurtunistic sleep shuts things down (causing the mail check to fail) System A will last considerably longer on a battery than System B. 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: Florian Mickler on 6 Jun 2010 06:50 On Sun, 6 Jun 2010 12:00:47 +0200 Vitaly Wool <vitalywool(a)gmail.com> wrote: > 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. That is not true. While the kernel is not suspended it does runtime pm. > > 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... ? Cheers, Flo -- 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: Florian Mickler on 6 Jun 2010 07:00
On Sun, 6 Jun 2010 12:19:08 +0200 Vitaly Wool <vitalywool(a)gmail.com> wrote: > 2010/6/6 <david(a)lang.hm>: > > > as an example (taken from this thread). > > > > system A needs to wake up to get a battery reading, store it and go back to > > sleep, It does so every 10 seconds. But when it does so it only runs the one > > process and then goes back to sleep. > > > > system B has the same need, but wakes up every 10 minutes. but when it does > > so it fully wakes up and this allows the mail app to power up the radio, > > connect to the Internet and start checking for new mail before oppurtunistic > > sleep shuts things down (causing the mail check to fail) > > > > System A will last considerably longer on a battery than System B. > > Exactly, thanks for pointing out the specific example :) > > ~Vitaly This does not affect suspend_blockers nor does suspend_blockers interfere with that. Suspend_blockers allow the system to suspend ("mem">/sys/power/state suspend), when the userspace decides that the device is not in use. So implementing suspend_blockers support does not impact any optimizations done to either system A nor system B. Cheers, Flo -- 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/ |