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

["Langsdorf, Mark" <mark.langsdorf@xxxxxxx>]

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



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