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] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, Mark Langsdorf <mark.langsdorf@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Fri, 31 Aug 2007 11:04:49 +0100
Delivery-date: Fri, 31 Aug 2007 03:06:01 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <D470B4E54465E3469E2ABBC5AFAC390F013B21AA@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acfqh8RwaTy8r4iaT0y7Njlwu+54dgAROIeQAAbzeNkAABsToAABWQIjAB9V6qAAErBLqw==
Thread-topic: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes
User-agent: Microsoft-Entourage/
On 31/8/07 02:20, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:

> Yes, that information has to be parsed and notified to Xen. Some PV l
> ogic needs to be hooked into cpufreq as you said. Userspace program
> is a good choice too, like the user level ACPI interpreter. However the
> major block is to parse dynamically changed information. For example,
> cpufreq info may change (due to some hardware events) and OSPM
> is required to re-evaluate P-state info. That re-evaluation may get
> different info after checking some hardware bits. To do it in user level,
> firstly we need emulate an event and then need virtualize those bits.
> Not very easy to track. So I more agree with you that an user-level
> stuff is the way to go, at least for the start.

Not sure what you're saying here. It seems to be 'getting async acpi events
in user space would be hard, so doing this stuff in user space is the way to
go'. The argument and conclusion seem at odds with one another.
Unfortunately I have to reluctantly agree with the argument: at least, it
would be some work to provide an interface to allow user processes to access
the ACPI event mechanism. I'm not sure how much. :-)

Personally I'd concentrate on picking out C-state control from ACPI, pass
that info down to Xen, and hook that into the idle-loop and cpu-hotplug
paths. Much easier, no async acpi events to worry about, and probably as
good or better power saving where you have more than a couple of cores.

 -- Keir

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>