Re: Performance difference between Xen versions

[John Weekes <lists.xen@nuclearfallout.net>]

On 5/2/2011 12:23 AM, Jan Beulich wrote:
> Correct. I generally found the default threshold of the ondemand
> governor nor very suitable for optimal performance of short lived
> jobs, and boot all of my systems with "cpufreq=xen:ondemand,threshold=20".

These pm comments made me wonder about turbo mode, which I've never seen 
working, and the fact that xenpm doesn't work for me either (for 
instance, trying to turn on turbo with it causes Xen to freeze). So, I 
started digging a bit.

I'm testing with 4.1. I started by setting my line to include the one 
that you gave as an example, but adding ",verbose=1" to the end in order 
to see more output. Strangely, I didn't see any, and turbo mode was 
still not being set (and frequencies weren't changing).

I added some further debug code and found that cpufreq_add_cpu was 
aborting because of its "if (!processor_pminfo[cpu])" check at the 
beginning. I can't find where processor_pminfo[cpu] would be set 
anywhere but in the set_px_pminfo hypercall (via copying), and I can't 
find a caller of that function anywhere in the Xen source or 
2.6.32-stable kernel source. I do see it mentioned in the old 2.6.18. Is 
this something that has yet to be ported to pv_ops, and are there plans 
to do so? Is there also the possibility of initializing it internally 
without dom0 interaction, when "xen" is chosen as the cpufreq scheduler?

Or I am I just missing something entirely here?

-John