From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from viefep15-int.chello.at (viefep15-int.chello.at [62.179.121.35]) by ozlabs.org (Postfix) with ESMTP id 8E40AB7B69 for ; Thu, 8 Oct 2009 23:26:56 +1100 (EST) Subject: Re: [v8 PATCH 2/8]: cpuidle: implement a list based approach to register a set of idle routines. From: Peter Zijlstra To: arun@linux.vnet.ibm.com In-Reply-To: <20091008120120.GL20595@linux.vnet.ibm.com> References: <20091008094828.GA20595@linux.vnet.ibm.com> <20091008095027.GC20595@linux.vnet.ibm.com> <1254998162.26976.270.camel@twins> <20091008104249.GJ20595@linux.vnet.ibm.com> <1254999033.26976.272.camel@twins> <20091008110106.GK20595@linux.vnet.ibm.com> <1255001110.26976.292.camel@twins> <20091008120120.GL20595@linux.vnet.ibm.com> Content-Type: text/plain Date: Thu, 08 Oct 2009 14:25:37 +0200 Message-Id: <1255004737.26976.307.camel@twins> Mime-Version: 1.0 Cc: linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, Ingo Molnar , linuxppc-dev@lists.ozlabs.org, Arjan van de Ven List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, 2009-10-08 at 17:31 +0530, Arun R Bharadwaj wrote: > > > Uhm, no, it would mean ACPI putting its idle routines on the same level > > as all others. > > > > Putting them all on the same level would mean, we need an > enable/disable routine to enable only the currently active routines. What's this enable/disable stuff about? > Also, the way governor works is that, it assumes that idle routines > are indexed in the increasing order of power benefit that can be got > out of the state. So this would get messed up. Right, which is why I initially had a power-savings field in my proposal, so it could weight the power savings vs the wakeup latency. http://lkml.org/lkml/2009/8/27/159 There it was said that was exactly what these governors were doing, seems its not. > > Sounds like something is wrong alright. If you can register an idle > > routine you should be able to unregister it too. > > > > Yes, we can register and unregister in a clean way now. > Consider this. We have a set of routines A, B, C currently registered. > Now a module comes and registers D and E, and later on at some point > of time wants to unregister. So how do you keep track of what all idle > routines the module registered and unregister only those? > Best way to do that is a stack, which is how I have currently > implemented. Right, so destroy that inner set thing, that way we only have one left ;-)