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: Vaidyanathan Srinivasan <svaidy@xxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [RFC PATCH V4 2/5] cpuidle: list based cpuidle driver registration and selection
From: Len Brown <lenb@xxxxxxxxxx>
Date: Fri, 25 Mar 2011 03:13:04 -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: Fri, 25 Mar 2011 00:14:07 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110324165200.GC16408@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> <20110324165200.GC16408@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.02 (LFD 1266 2009-07-14)
> > 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.

One reason I'd like a default cpuidle driver is that today
there is a race.  cpuidle registers, but until its driver
registers it will use polling.  go ahead and look:

grep . /sys/devices/system/cpu/cpu*/cpuidle/state0/usage

that should be 0, but it isn't...

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

Right, though I don't share your fascination with modules.

Len Brown, Intel Open Source Technology Center

Xen-devel mailing list