Suspend block api (version 8)
in [Kernel]
|
From: Peter Zijlstra on 26 May 2010 06:00 On Wed, 2010-05-26 at 11:40 +0200, Florian Mickler wrote: > On Wed, 26 May 2010 10:45:33 +0200 > Peter Zijlstra <peterz(a)infradead.org> wrote: > > > On Mon, 2010-05-24 at 02:46 +0200, Rafael J. Wysocki wrote: > > > On Saturday 22 May 2010, Arve Hjønnevåg wrote: > > > > This patch series adds a suspend-block api that provides the same > > > > functionality as the android wakelock api. This version adds a > > > > delay before suspending again if no suspend blockers were used > > > > during the last suspend attempt. > > > > > > Patches [1-6/8] applied to suspend-2.6/linux-next > > > > So you're going to merge this junk? > > > > > > Yes. By now, everyone reading the posts should know all points. > Raffael obviously was part of this discussion and came to the decision > to merge it. > > My take of the discussion: > _IF_ you want to suspend aggressively, I don't see another > way. > > The thing is, this is a paradigm change. Suspend is not anymore > controlled by userspace. In order to let userspace control/work with > this scheme, it needs to know when a suspend will be successfull or > poll: > > 1. kernel sees suspend may be possible on his side of things > > 2. kernel sends a message to userspace that i could be possibly > possible to suspend, but it may well be that by the time > userspace suspends it is not possible anymore > > 3. userspace decides to suspend. > > <- system suspends... or not ..-> > > 4. userspace retries ... retries ... retries ... > > And then you have the whole can of worms and races. I don't see any races, nor retry loops. There is always the race of an event arriving whilst in the process of suspending, that is not solved by either the kernel nor user part of suspend-blockers. The only thing is not to loose the event. You simply have to deal with that, the suspend gets canceled, you do deal with the event, and suspend again. How does making that 'retry' as you call it happen from a kernel thread or from a userspace thread any difference? -- 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 26 May 2010 06:10 On Wed, 26 May 2010 11:45:06 +0200 Peter Zijlstra <peterz(a)infradead.org> wrote: > On Wed, 2010-05-26 at 02:41 -0700, Arve Hj�nnev�g wrote: > > On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra <peterz(a)infradead.org> wrote: > > > On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote: > > >> > This of course will lead to a scattering of suspend blockers into any > > >> > drivers/subsystems considered "useful", which by looking through current > > >> > Android kernels is many of them. > > >> > > >> That depends on the maintainers of these subsystems, who still have the power > > >> to reject requested changes. > > > > > > So as a scheduler maintainer I'm going to merge a patch that does a > > > suspend_blocker when the runqueue's aren't empty... how about that? > > > > > > > I don't know if you are serious, since the all the runqueues are never > > empty while suspending, this would disable opportunistic suspend > > altogether. > > So why again was this such a great scheme? Go fix your userspace to not > not run when not needed. Hi Peter! This was already mentioned in one of these threads. 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. Cheers, Flo > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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:10 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? -- 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:10 2010/5/26 Peter Zijlstra <peterz(a)infradead.org>: > On Wed, 2010-05-26 at 02:41 -0700, Arve Hj�nnev�g wrote: >> On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra <peterz(a)infradead.org> wrote: >> > On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote: >> >> > This of course will lead to a scattering of suspend blockers into any >> >> > drivers/subsystems considered "useful", which by looking through current >> >> > Android kernels is many of them. >> >> >> >> That depends on the maintainers of these subsystems, who still have the power >> >> to reject requested changes. >> > >> > So as a scheduler maintainer I'm going to merge a patch that does a >> > suspend_blocker when the runqueue's aren't empty... how about that? >> > >> >> I don't know if you are serious, since the all the runqueues are never >> empty while suspending, this would disable opportunistic suspend >> altogether. > > So why again was this such a great scheme? Go fix your userspace to not > not run when not needed. > 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. -- 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:20
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? Is it because you're using broken hardware that has lower power consumption in suspend state as in idle? Couldn't you make the runtime-pm smarter and utilize the suspend states? -- 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/ |