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: Len Brown <lenb@xxxxxxxxxx>
Subject: [Xen-devel] Re: [RFC PATCH V4 2/5] cpuidle: list based cpuidle driver registration and selection
From: Trinabh Gupta <trinabh@xxxxxxxxxxxxxxxxxx>
Date: Wed, 23 Mar 2011 14:52:37 +0530
Cc: venki@xxxxxxxxxx, ak@xxxxxxxxxxxxxxx, suresh.b.siddha@xxxxxxxxx, sfr@xxxxxxxxxxxxxxxx, peterz@xxxxxxxxxxxxx, benh@xxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, arjan@xxxxxxxxxxxxxxx
Delivery-date: Thu, 24 Mar 2011 16:58:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.LFD.2.02.1103222254420.10549@x980>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100621 Fedora/3.0.5-1.fc11 Thunderbird/3.0.5
Hi Len,

The goal of the patch series is to remove exported pm_idle function
pointer (see http://lkml.org/lkml/2009/8/28/43 and
http://lkml.org/lkml/2009/8/28/50 for problems related to pm_idle).
The first patch in the series removes pm_idle for x86 and we
now directly call cpuidle_idle_call as suggested by Arjan

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.

In theory I agree that we can maybe do without list based
registration i.e probe and pick the best for the platform, but things
may become less predictable and difficult to manage as
we have more and more platforms and drivers.
By directly calling into cpuidle, we already have arch default
other than intel_idle and acpi_idle. Then APM and xen (though
it uses default_idle) also have their own idle routines.
List based management and selection based on priority would provide
a cleaner solution.


On 03/23/2011 08:29 AM, Len Brown wrote:
the original cpuidle prototype supported multiple driver registration,
but no production use for it could be imagined, and so it was deleted.

Subsequently on x86, we added intel_idle to replace acpi_idle
and a typical kernel will have them both built in.
We still don't allow mutliple registrations, we just arrange
affairs such that the preferred intel_idle probes before
the backup, acpi_idle.  If intel_idle recognizes the platform,
its probe succeeds, else acpi_idle gets a go.
If there is a problem with intel_idle, or a comparison needs to be made,
a bootparam is available to tell intel_idle not to probe.

This mechanism takes approximately 10 lines of code -- the bootparam
to disable the preferred driver.

What is the benefit of all the code to support the feature of run-time
multiple driver registration and switching?

Len Brown, Intel Open Source Technology Center

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Xen-devel mailing list