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>, xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes
From: "Langsdorf, Mark" <mark.langsdorf@xxxxxxx>
Date: Thu, 30 Aug 2007 09:57:49 -0500
Delivery-date: Thu, 30 Aug 2007 07:58:37 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <D470B4E54465E3469E2ABBC5AFAC390F013B21A3@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>
References: <200708291702.33634.mark.langsdorf@xxxxxxx> <D470B4E54465E3469E2ABBC5AFAC390F013B21A3@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acfqh8RwaTy8r4iaT0y7Njlwu+54dgAROIeQABH1zfA=
Thread-topic: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes
> 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. 

Supporting cpufreq in Xen requires the ability to parse
ACPI or a new dom0 driver to pass ACPI data to Xen, as 
well as a mechanism for setting policy.  Since dom0 
already has both of those, I really think making it work
in dom0 is simplest.

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

I thought I had everything, but I'll repost as four patches to be sure.
> 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 
> changes
>       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
> offset.
>   So I think one thing you can try is to stop calibration 
> timer at t1',  change scale, and then restart calibration timer again.
> the mismatch between [t1, t1'] is difficult to be solved unless in-xen

> governor is used. :-)

Xen accepts some error in the time-keeping code.  Changing at t'
seems to reduce the error to acceptable margins.

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

Good idea.  I'll look into adding that, but it's a minor fix 
compared to the main code.

-Mark Langsdorf
Operating System Research Center

Xen-devel mailing list