This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [RFC PATCH V4 2/5] cpuidle: list based cpuidle drive

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [RFC PATCH V4 2/5] cpuidle: list based cpuidle driver registration and selection
From: Len Brown <lenb@xxxxxxxxxx>
Date: Wed, 30 Mar 2011 22:25:36 -0400 (EDT)
Cc: venki@xxxxxxxxxx, ak@xxxxxxxxxxxxxxx, suresh.b.siddha@xxxxxxxxx, sfr@xxxxxxxxxxxxxxxx, peterz@xxxxxxxxxxxxx, benh@xxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, arjan@xxxxxxxxxxxxxxx, Trinabh Gupta <trinabh@xxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 30 Mar 2011 19:26:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110325153524.GN27651@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20110322123208.28725.30945.stgit@xxxxxxxxxxxxxxxxxxx> <20110322123233.28725.92874.stgit@xxxxxxxxxxxxxxxxxxx> <alpine.LFD.2.02.1103222254420.10549@x980> <4D89BBDD.5090505@xxxxxxxxxxxxxxxxxx> <alpine.LFD.2.02.1103231633030.12911@x980> <4D8B5197.2060306@xxxxxxxxxxxxxxxxxx> <alpine.LFD.2.02.1103250245570.32565@x980> <20110325153524.GN27651@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.02 (LFD 1266 2009-07-14)

Len Brown, Intel Open Source Technology Center

On Fri, 25 Mar 2011, Konrad Rzeszutek Wilk wrote:

> 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?

I don't think Xen needs a cpuidle driver.
Xen just needs to tell the kernel to call HALT,
and I think we'll keep that around for the non-cpuidle case,
and for the idle periods before cpuidle initializes.

Len Brown, Intel Open Source Technology Center

Xen-devel mailing list