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

Re: [Xen-devel] Performance difference between Xen versions



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

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


 


Rackspace

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