[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes

  • To: "Mark Langsdorf" <mark.langsdorf@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • 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
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • 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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.