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: Thu, 30 Aug 2007 17:45:39 +0800
Delivery-date: Thu, 30 Aug 2007 03:04:41 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2FC4CDB.1504D%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: <D470B4E54465E3469E2ABBC5AFAC390F013B21A3@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C2FC4CDB.1504D%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acfqh8RwaTy8r4iaT0y7Njlwu+54dgAROIeQAAbzeNkAABsToA==
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日 17:31
>On 30/8/07 07:41, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>> a) Current approach is simple to let Dom0 conduct frequency
>> change. That should be OK in the start, but at the same time we
>> should also consider the on-demand governor within Xen itself.
>> Xen can always get first-hand data about domain status, while
>> dom0 (either user-level or in-kernel) can't achieve in time. Fine-
>> grained frequency change is more likely to be achieved within
>> Xen directly.
>Personally I'm a fan of doing it in dom0 userspace, although doing it
>Xen can also be argued for. Doing it in dom0 kernel doesn't seem very
>attractive apart from the obvious pragmatic advantage that all the code is
>already in the Linux kernel. :-)

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. :-)

>If we're doing it in the Linux kernel, I don't see much point in hacking up
>the defunct powernow (or equivalent Intel) code. Why not fix the generic
>acpi-cpufreq.c? That is supposed to work on any modern CPU. I'm not
>sure the
>2.6.18 version is new enough, but I'd rather see a backported and fixed
>version of that file, rather than bother to maintain modified versions of
>obsolete source files.



Xen-devel mailing list