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: "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 14:41:14 +0800
Delivery-date: Wed, 29 Aug 2007 23:41:47 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <200708291702.33634.mark.langsdorf@xxxxxxx>
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: <200708291702.33634.mark.langsdorf@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acfqh8RwaTy8r4iaT0y7Njlwu+54dgAROIeQ
Thread-topic: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes
Hi, Mark,
        Some comments here:

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.

b) Did you miss some part of patch? I didn't see place within Xen 
to handle new platform hypercall. Also please don't mix Linux and 
Xen change altogether in one patch.

c) I took a look at your previous version. It seemed that you need do 
some change to Xen's calibration code. The calibration happens once 
per second on local processor. Say [start,end] of calibration period is 
[t0, t2], and frequency change happens at [t1] and Xen is notified with 
that event at [t1']. Here we get several problematic window:
        t1 < t < t1': dom0 still uses old scale while TSC frequency already 
        t1' < t < t2: dom0 uses right scale matching TSC change
        t2: Xen runs its calibration timer while this period is with mixed 
frequency and Xen will get a new frequency [new'] something between
[old, new]. Such mismatch may make dom0 misinterpret elapsed TSC
  So I think one thing you can try is to stop calibration timer at t1', 
change scale, and then restart calibration timer again. But the mismatch 
between [t1, t1'] is difficult to be solved unless in-xen governor is used. :-)

d) How about adding a 'cpufreq' boot option? Once it's on, 
dom0_vcpus_pin is forced to on too. Or else it really doesn't make 
sense to let dom0 conduct frequency change.


>From: Mark Langsdorf
>Sent: 2007年8月30日 6:03
>Enable cpufreq support in Xen for AMD Operton processors by:

Xen-devel mailing list