Suspend block api (version 8)
in [Kernel]
|
From: Florian Mickler on 26 May 2010 06:20 On Wed, 26 May 2010 12:08:04 +0200 Peter Zijlstra <peterz(a)infradead.org> wrote: > On Wed, 2010-05-26 at 12:02 +0200, Florian Mickler wrote: > > The summary is: The device this kernel is running on dosn't want to > > (or can) rely on userspace to save power. This is because it is an open > > system, without an app-store or the like. Everyone can run what he > > wants. > > > > So anything relying on (all) userspace solves a different problem. > > So what stops an application from grabbing a suspend blocker? Well, I don't own any android devices, but If I read this all correctly, an app can request the permission to grab an suspend blocker at installation time. ("This application is requesting permission to keep the device from sleeping, thus possibly reducing your battery time. Are you shure you want to continue? [Yes,No]") every app grabbing a suspend blocker is showing up in a "these programs stop suspend" kind of battery-app and are thus well accounted for. _And the user knows who to blame_. Maybe this is implemented via fs-permissions? Anyway, I'm shure, that the access control uses a well established method. :) 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: Arve Hjønnevåg on 26 May 2010 06:30 2010/5/26 Peter Zijlstra <peterz(a)infradead.org>: > On Wed, 2010-05-26 at 03:06 -0700, Arve Hj�nnev�g wrote: > >> I was not talking about our user-space code. Suspend has to be called >> by a running thread, so at least one runqueue is not empty. > > But why would you need to suspend if the machine is fully idle? > I have never seen a system that is fully idle for hours or even minutes. > Is it because you're using broken hardware that has lower power > consumption in suspend state as in idle? > Initially, yes, but for shipping android phones, no. > Couldn't you make the runtime-pm smarter and utilize the suspend states? > I don't think runtime-pm is relevant here. We don't use suspend to power down devices that are not in use, we use suspend to enter system power states that we cannot enter from idle, and on systems where the same power state can be used from idle and suspend, we use suspend so we can stay in the low power state for minutes to hours instead of milliseconds to seconds. -- Arve Hj�nnev�g -- 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: Peter Zijlstra on 26 May 2010 06:40 On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote: > and on systems where the > same power state can be used from idle and suspend, we use suspend so > we can stay in the low power state for minutes to hours instead of > milliseconds to seconds. So don't you think working on making it possible for systems to be idle _that_ long would improve things for everybody? as opposed to this auto-suspend which only improves matters for those that (can) use it? -- 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: Peter Zijlstra on 26 May 2010 06:50 On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote: > 2010/5/26 Peter Zijlstra <peterz(a)infradead.org>: > > On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote: > > > >> and on systems where the > >> same power state can be used from idle and suspend, we use suspend so > >> we can stay in the low power state for minutes to hours instead of > >> milliseconds to seconds. > > > > So don't you think working on making it possible for systems to be idle > > _that_ long would improve things for everybody? as opposed to this > > auto-suspend which only improves matters for those that (can) use it? > > I'm not preventing anyone from working on improving this. Currently > both the kernel and our user-space code polls way too much. I don't > think it is reasonable to demand that no one should run any user-space > code with periodic timers when we have not even fixed the kernel to > not do this. All I'm saying is that merging a stop-gap measure will decrease the urgency and thus the time spend fixing the actual issues while adding the burden of maintaining this stop-gap measure. -- 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 26 May 2010 06:50
On Wed, May 26, 2010 at 3:32 AM, Peter Zijlstra <peterz(a)infradead.org> wrote: > On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote: > >> and on systems where the >> same power state can be used from idle and suspend, we use suspend so >> we can stay in the low power state for minutes to hours instead of >> milliseconds to seconds. > > So don't you think working on making it possible for systems to be idle > _that_ long would improve things for everybody? as opposed to this > auto-suspend which only improves matters for those that (can) use it? As we've stated a number of times in the several weeks of discussion (this time around) of this patchset, we are all in favor of improving runtime pm, finding and resolving issues that prevent idle, and heading toward ever lower power states in idle -- after all, this benefits our battery life in the cases when the system is not suspended as well as moving us closer to a future where the power savings between actively entering suspend and not doing so approach zero. Aggressively entering the lowest possible power state at all times is our goal here. At the moment, the power savings from opportunistic suspend do directly lead to improved battery life, and there are some advantages to this model in the face of a non-optimal userspace (as we encounter in a world where there are not restrictions on what applications users may install and run). 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/ |