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


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

To: Trinabh Gupta <trinabh@xxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [RFC PATCH V4 2/5] cpuidle: list based cpuidle driver registration and selection
From: Vaidyanathan Srinivasan <svaidy@xxxxxxxxxxxxxxxxxx>
Date: Thu, 24 Mar 2011 22:22:00 +0530
Cc: venki@xxxxxxxxxx, ak@xxxxxxxxxxxxxxx, suresh.b.siddha@xxxxxxxxx, sfr@xxxxxxxxxxxxxxxx, peterz@xxxxxxxxxxxxx, benh@xxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, arjan@xxxxxxxxxxxxxxx, Len Brown <lenb@xxxxxxxxxx>
Delivery-date: Thu, 24 Mar 2011 17:14:33 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D8B5197.2060306@xxxxxxxxxxxxxxxxxx>
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>
Reply-to: svaidy@xxxxxxxxxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-06-14)
* Trinabh Gupta <trinabh@xxxxxxxxxxxxxxxxxx> [2011-03-24 19:43:43]:


> >>But we also have to replace the functionality provided by pm_idle,
> >>i.e. call default_idle for platforms where no better idle routine
> >>exists, call mwait for pre-nehalem platforms, use intel_idle or
> >>acpi_idle for nehalem architectures etc. To manage all this
> >>we need a registration mechanism which is conveniently provided
> >>by cpuidle.
> >
> >It isn't immediately clear to me that all of these options
> >need to be preserved.
> So what do you suggest can be removed?

Can we use safe_halt() until intel_idle/acpi_idle take over? But what
if they do not take over?  If safe_halt() is not very bad compared to
the variants like mwait_idle and c1e_idle, then we can remove the old
code and no need to move them to default driver.

> >Are we suggesting that x86 must always build with cpuidle?
> >I'm sure that somebody someplace will object to that.
> Arjan argued that since almost everyone today runs cpuidle
> it may be best to include it in the kernel
> (https://lkml.org/lkml/2010/10/20/243). But yes, we agreed
> that we would have to make cpuidle lighter incrementally.
> Making ladder governor optional could be one way for example.
> >
> >OTOH, if cpuidle is included, I'd like to see the
> >non-cpuidle code excluded, since nobody will run it...

The non-cpuidle code will be the select_idle_routine() and related
function that cam move to default_driver that register to cpuidle.
We can load on-demand as module if better routines fail to register.
Maybe we don't need this at all as discussed in the above point?



Xen-devel mailing list