From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trinabh Gupta Subject: Re: [RFC PATCH V4 5/5] cpuidle: cpuidle driver for apm Date: Thu, 24 Mar 2011 19:58:29 +0530 Message-ID: <4D8B550D.5000409@linux.vnet.ibm.com> References: <20110322123208.28725.30945.stgit@tringupt.in.ibm.com> <20110322123336.28725.29810.stgit@tringupt.in.ibm.com> <20110323121458.ec7cdaf9.sfr@canb.auug.org.au> <4D89CA7D.8080108@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Len Brown , arjan@linux.intel.com Cc: Stephen Rothwell , peterz@infradead.org, suresh.b.siddha@intel.com, benh@kernel.crashing.org, venki@google.com, ak@linux.intel.com, linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 03/24/2011 02:02 AM, Len Brown wrote: >>> Also wondering why you would ever have a different idle routine on >>> different cpus? >> >> Yes, this is an ongoing debate. Apparently it is a possibility >> because of ACPI bugs. CPU's can have asymmetric C-states >> and overall different idle routines on different cpus. Please >> refer to http://lkml.org/lkml/2009/9/24/132 and >> https://lkml.org/lkml/2011/2/10/37 for a discussion around this. > > Althought the ACPI specification allows the BIOS to tell the OS > about different C-states per-processor, I know of zero system > in the field and zero systems in development that require that > capability. That isn't a guarantee that capability will never > be used, but I'm not holding my breath. > > If there are systems with broken tables that make them > appear asymetric, then we should have a workaround that handles > that case, rather than complicating the normal code for > the broken case. > > So I recommend deleting the extra per-cpu registration stuff > unless there is some other architecture that requires it > and can't hadle the asymmetry in another way. Yes, lets go forward with removal of per-cpu registration and handle rare case of asymmetry in some other may. Using intersection or union of C-states for each cpu may be a solution. Using intersection or lowest common C-state has the corner case that we could have packages/cores supporting a new lower C-state in case of thermal limit and they would want OS to go to this state. Using intersection or lowest common C-state may prevent this. Another option is to use union of C-states; but I am not sure what happens if a CPU uses a state that is not reported for it??? Maybe there is some other way to handle asymmetry ?? > >> I have posted a patch series that does global registration >> i.e same idle routines for each cpu. Please check >> http://lkml.org/lkml/2011/3/22/161 . That series applies on >> top of this series. Global registration significantly >> simplifies the design, but still we are not sure about the >> direction to take. > > I'll review that. Thanks; please review especially the data structure changes https://lkml.org/lkml/2011/3/22/162 -Trinabh