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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

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

Thanks,
Kevin

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel