Re: [Xen-users] Setting CPU (core) frequency from dom0
As it turns out, my problem was due to not having all of the right options set for the dom0 kernel (in the .config file). The one option that got me is CONFIG_X86_POWERNOW_K8_ACPI. As it turns out, that option, when not set, replaces a number of the functions in powernow-k8.c with stubs that return -ENODEV.
Once I got that option set, everyting worked as it should.
For those of you interested, here is what I did:
- set cpufreq=dom0-kernel option for the kernel line in the grub menu file (/boot/grub/menu.lst for ubuntu distributions)
- set option CONFIG_CPU_FREQ for the dom0 kernel (I added an entry to linux-2.6.18-xen.hg/arch/x86_64/Kconfig)
- Ensure that CONFIG_ACPI_PROCESSOR is set to "y" (not "m"!) in the configuration file. In my case this option was set to "m", and that was preventing CONFIG_X86_POWERNOW_K8_ACPI from being set.
- Use the sysfs interface (/sys/devices/system/cpu/cpu*/cpufreq/) to set the CPUs to the desired frequency.
On Sun, Nov 23, 2008 at 9:06 PM, Tian, Kevin <kevin.tian@xxxxxxxxx>
We can copy you in the CC list when submitting
Yes, that would be great. Thank you.
We didn't try mode A on 3.3, since we don't think it
right thing to do. But from what you have done, it looks enough.
Yes, I works just fine.
Thank you for all the help.
On Thu, Nov 20, 2008 at 7:02 PM, Tian, Kevin <kevin.tian@xxxxxxxxx>
be in one or two weeks, and now coding is close to end (by
Jinsong). This patch sets will cover many control bits besides
allowing user to change freq as I said
Excellent! How do I find out when the patch has been made
For the code you mentioned, it's one bug since as you cited
that return-0 means success. However it looks that this warning doesn't hurt
printk(KERN_ERR "failed to set up cpufreq
registered successfully and there's no code to reverse the effect even when
-ENODEV is returned. :-)
Yes, I figured that out yesterday. Other than printing the error, the
system does nothing with the -ENODEV return. Still, I am not getting a sysfs
interface for cpufreq and I haven't been able to figure out why.
BTW in xen3.2,
In case this was not clear, I am trying to use method A
(cpufreq=dom0-kernel) with Xen 3.3 (not 3.2). Does that not work in Xen
Also, do you happen to know of a place where I can get a list of what
needs to be set up in order to get this frequency scaling to work. I am pretty
sure that my problem with not getting the sysfs interface for cpufreq (it is
available for other things) is related to something I am missing in the
configuration. So far, what I have done (for method A) is:
- Set the option cpufreq=dom0-kernel as an option to the Xen hypervisor
- Disable PROCESSOR_EXTERNAL_CONTROL in drivers/acpi/Kconfig (for
- Enable CONFIG_CPU_FREQ for dom0 (I did this from
Perhaps there is a BIOS setting for the CPU that I am unaware of (my
machine is using Barcelona CPUs)?
Thank you very much for the
PLease see comments below.
On Wed, Nov 19, 2008 at 7:05 PM, Tian, Kevin <kevin.tian@xxxxxxxxx>
description is basically correct. Do you want to control cpu frequency
from dom0 user level, or just try cpufreq governor in dom0?
I would like to control frequency from dom0. I want to
arbitrarily set the CPU frequency to a value and have it stay there
(regardless of the load on that CPU) until I change
the former, we're currently adding more flexibility to xen cpufreq (such as
user space governor) and control options to xenpm (such as manually
changing freq), which is expected to reach xen upstream soon.
Yes, I thik this is what I need (ability to manually change
frequency). Do you have an ETA (estimated time of arrival) for that
the latter, it's suboptimal with limitations which is why xen cpufreq is
develeoped. You may manually disable PROCESSOR_EXTERNAL_CONTROL in
drivers/acpi/Kconfig to rebuild dom0 kernel for mode
OK. I will do that.
By the way, I have been running
onto an error when booting (in mode A). The function
cpufreq_time_setup() in linux-2.6.18-xen.hg/arch/i386/kernel/time-xen.c is
printing the following message during boot (and returning -ENODEV to its
failed to set up cpufreq notifier
Further examination of the code
shows that this happens when notifier_chain_register() in
linux-2.6.18-xen.hg/kernel/sys.c returns 0. The problem is that in the
code I have, that function ALWAYS returns 0. The code for that function is
static int notifier_chain_register(struct
while ((*nl) != NULL)
if (n->priority >
n->next = *nl;
think (but are not 100%
sure yet) that as a result of this error, dom0 is not creating a cpufreq
/sys interface (i.e
happen to know what may be going on? perhaps I am just misreading the
code? or perhaps not disabling PROCESSOR_EXTERNAL_CONTROL is what is causing this
behavior? I will run some experiments on this last thing
I am running some experiments that
require changing the frequency of a CPU in a SunFire machine (32-core
quad socket AMD Barcelona).
For what I have found (bits and
pieces but not a comprehensive description), there are two meachisms
for controlling core (most probably socket) frequency in
A- The older (xen-3.2.1) mechnism through dom0 (option
cpufreq=dom0-kernel), which for what I gather uses a module in dom0
(cpufreqd?) that allows one to set cpu frequency.
B- The newer
(xen-3.3), which has moved the governor to the hypervisor (option
cpufreq=xen), which other than a utility to read processor P and C
states (xenpm) does not (yet) allow user (dom0) control of CPU
My first question is whetherot what I have written
above is accurate. My second question is where can I find detailed
information on how to set up my system to make use of A above and be
able to set cpu frequency "manually" from Dom0 (assuming that is still
possible in Xen 3.3).
I am running the latest testing version
of Xen 3.3 (about a week old).
Any information would be greatly
Xen-users mailing list