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: "Keir Fraser" <keir@xxxxxxxxxxxxx>, "Mark Langsdorf" <mark.langsdorf@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Fri, 31 Aug 2007 09:20:19 +0800
Delivery-date: Thu, 30 Aug 2007 18:20:46 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2FC569C.15063%keir@xxxxxxxxxxxxx>
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>
References: <D470B4E54465E3469E2ABBC5AFAC390F013B21A8@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C2FC569C.15063%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acfqh8RwaTy8r4iaT0y7Njlwu+54dgAROIeQAAbzeNkAABsToAABWQIjAB9V6qA=
Thread-topic: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes
>From: Keir Fraser [mailto:keir@xxxxxxxxxxxxx]
>Sent: 2007年8月30日 18:12
>On 30/8/07 10:45, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>> Sure, some experiment can be done later to compare dom0 userspace
>> and in-xen governor. Agree that in-kernel dom0 approach is not
>> charming because anyway it needs help from either user-level or xen
>> for global view.
>> Actually finally we may take both. Xen takes simple heuristic policy
>> with user-level governor to adjust with more complex and flexible
>> policies based on domain behaviors. :-)
>There is the problem, though, that most modern CPUs will need cpufreq
>to be parsed out of the ACPI DSDT. And Xen can't do that itself unaided.
>Pushing down some form of cpufreq info table to Xen *is* an option
>but we'd need more custom dom0 kernel code to do that. Or we'd need
>to do it
>from a userspace program.
> -- Keir

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.


Xen-devel mailing list

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