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: Alan Stern on 5 Jun 2010 22:50 On Sat, 5 Jun 2010, Arve Hj�nnev�g wrote: > Yes, we can keep all our user space suspend blockers and thaw the > frozen cgroup when any suspend blocker is held, but this would > eliminate any power advantage that freezing a cgroup has over using > suspend to freeze all processes. Without annotating the drivers to > block the cgroup freezing in the same places as we now block suspend, > it also prevents processes in the cgroup that we freeze from directly > consuming wakup events. The driver annotations don't need to block the cgroup freezing. They just need to keep the system running long enough to awaken a thread that will handle the wakeup event. (See below.) A pm-qos constraint is good enough for this. > If you are referring to the approach that we don't use suspend but > freeze a cgroup instead, this only solves the problem of bad apps. It > does not help pause timers in trusted user space code and in the > kernel, so it does not lower our average power consumption. You can solve this problem if you restructure your "trusted" apps in the right way. Require a trusted app to guarantee that whenever it doesn't hold any suspend blockers, it will do nothing but wait (in a poll() system call for example) for a wakeup event. When the event occurs, it must then activate a suspend blocker. Better yet, make it more fine-grained. Instead of trusted apps, have trusted threads. Freeze the untrusted threads along with everything else, and require the trusted threads to satisfy this guarantee. In this way, while the system is idle no user timers will get renewed. Kernel timers are another matter, but we should be able to handle them. There's nothing Android-specific about wanting to reduce kernel timer wakeups while in a low-power mode. > And, it > does not solve the problem for systems that enters lower power states > from suspend than it can from idle. The last point my not be relevant > to android anymore, but desktop systems already have auto suspend and > it would be preferable to have a race free kernel api for this. This is an entirely different matter from the rest of the discussion. It would be better to consider this separately after Android's current problems have been addressed. Alan Stern -- 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:00 2010/6/5 Arve Hj�nnev�g <arve(a)android.com>: > On Sat, Jun 5, 2010 at 9:28 AM, Arjan van de Ven <arjan(a)infradead.org> wrote: >> On Sat, 05 Jun 2010 11:54:13 +0200 >> Peter Zijlstra <peterz(a)infradead.org> wrote: >> >>> On Fri, 2010-06-04 at 17:10 -0700, Arve Hj�nnev�g wrote: >>> > > Trusted processes are assumed to be sane and idle when there is >>> > > nothing for them to do, allowing the machine to go into deep idle >>> > > states. >>> > > >>> > >>> > Neither the kernel nor our trusted user-space code currently meets >>> > this criteria. >>> >>> Then both need fixing. Really, that's the only sane approach. >> >> fwiw... in MeeGo we're seeing quite good idle times (> 1 seconds) >> without really bad hacks. >> > > 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? ~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 04:10 On Fri, 4 Jun 2010, Brian Swetland wrote: > Yeah, I do understand that we're not making it easy for ourselves > here. I think we hit the point where Rafael and Matthew signed off on > things and thought "aha, linux-pm maintainers are happy, now we're > getting somewhere" only to realize the light at the end of the tunnel > was a bit further out than we anticipated ^^ What you missed is that the linux-pm maintainers have relativly little weight in getting things into the kernel. They are gatekeeper, so until they approve it there is basically no chance of getting in, but even changes that they develop and push frequently have a uphill battle to get into the kernel, especially if they would end up touching all drivers. There have been several proposals by the pm team that have been shot down much more completely than wavelocks. 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: david on 6 Jun 2010 04:20 On Thu, 3 Jun 2010, Arjan van de Ven wrote: > On Thu, 3 Jun 2010 19:26:50 -0700 (PDT) > Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > >> >> If the system is idle (or almost idle) for long times, I would >> heartily recommend actively shutting down unused cores. Some CPU's >> are hopefully smart enough to not even need that kind of software >> management, but I suspect even the really smart ones might be able to >> take advantage of the kernel saying: "I'm shutting you down, you >> don't have to worry about latency AT ALL, because I'm keeping another >> CPU active to do any real work". > > sadly the reality is that "offline" is actually the same as "deepest C > state". At best. > > As far as I can see, this is at least true for all Intel and AMD cpus. > > And because there's then no power saving (but a performance cost), it's > actually a negative for battery life/total energy. I believe that this assumes you are in the 'race to idle' situation where when you finish your work you can shutdown. If the work is ongoing you may never shutdown. Also, what about the new CPUs where you can ramp up the clockspeed on some cores if you hsut down other cores? that couls also benifit individual threads. 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: Brian Swetland on 6 Jun 2010 04:30
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. 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/ |