From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Re: [RFC PATCH V4 2/5] cpuidle: list based cpuidle driver registration and selection Date: Fri, 25 Mar 2011 11:35:24 -0400 Message-ID: <20110325153524.GN27651@dumpdata.com> References: <20110322123208.28725.30945.stgit@tringupt.in.ibm.com> <20110322123233.28725.92874.stgit@tringupt.in.ibm.com> <4D89BBDD.5090505@linux.vnet.ibm.com> <4D8B5197.2060306@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Len Brown Cc: Trinabh Gupta , venki@google.com, ak@linux.intel.com, suresh.b.siddha@intel.com, sfr@canb.auug.org.au, peterz@infradead.org, benh@kernel.crashing.org, linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, arjan@linux.intel.com List-Id: xen-devel@lists.xenproject.org On Fri, Mar 25, 2011 at 03:05:36AM -0400, Len Brown wrote: > > I think there are other problems too, related to saving and restoring > > of pm_idle pointer. For example, cpuidle itself saves current value > > of pm_idle, flips it and then restores the saved value. There is > > no guarantee that the saved function still exists. APM does exact > > same thing (though it may not be used these days). > > > > The problem also is that a number of architectures have copied the > > same design based on pm_idle; so its spreading. > > pm_idle is a primitive design yes, but I think the issue > with pm_idle is a theoretical one, at least on x86; > as there isn't any other code scribbling on pm_idle > in practice. So this is clean-up, rather than bug-fix work... > > > > It isn't immediately clear to me that all of these options > > > need to be preserved. > > > > So what do you suggest can be removed? > > I sent a series of small patches yesterday to get the ball rolling... > https://lkml.org/lkml/2011/3/24/54 > > I think the xen thing can go away. The xen thing being the setting of cpuidle to halt or the proposed patch?