[Xen-devel] RE: Xen 3.4 / cpufreq=dom0-kernel / ondemand govenor doesn't step

["Liu, Jinsong" <jinsong.liu@xxxxxxxxx>]

Carsten Schiers wrote:
> I have just upgraded to Xen 3.4 and its kernel. I use
> cpufreq=dom0-kernel. I set
> the governor to ondemand. In the same setting as Xen 3.3.1 it now
> doesn't step
> upwards, even when I create heavy load. Transistion table demonstrates
> that:
> 
> data://sys/devices/system/cpu/cpu0/cpufreq/stats# cat trans_table
>    From  :    To
>          :   2100000   2000000   1800000   1000000
>   2100000:         0         0         0         2
>   2000000:         0         0         0         0
>   1800000:         0         0         0         0
>   1000000:         1         0         0         0
> 
> after an uptime of 30 minutes. The steps shown here came from a manual
> setting
> whilst I set the governor back to userspace. Any idea how to check
> further?
> 
> Does http://xenbits.xensource.com/xen-unstable.hg?rev/674e4d43955f
> make any
> difference in my case? As said, I used the tarballs.
> 
> And by the way: what is the actual xen-3.4 testing, I am a bit lost on
> the website.
> 
> BR,
> Carsten.

Carsten Schiers,

Actually xen cpufreq default option is 'cpufreq=xen', means xen hypervisor will 
take charge of cpufreq logic, you can try this option.
'cpufreq=dom0-kernel' means dom0 will take charge of cpufreq logic, but this 
part was not maintained by me.

http://xenbits.xensource.com/xen-unstable.hg?rev/674e4d43955f is not related to 
'cpufreq=dom0-kenrel' option.

If you use 'cpufreq=xen', you can set cpufreq para (governor, speed, 
sampling-rate, threshold, etc.) by grub cmdline at booting time, or by xenpm 
tools at runtime.
currently xenpm tools implement all para same as you can get&set from native 
linux /sys/devices/system/cpu/cpux/cpufreq interface.

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