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

Re: [Xen-devel] Using collectd: CPUFreq in dom0

On Fri, Jan 04, 2013 at 10:29:25PM +0100, Stefan Kuhne wrote:
> Am 04.01.2013 22:11, schrieb Konrad Rzeszutek Wilk:
> > On Tue, Dec 25, 2012 at 07:55:37PM +0100, Stefan Kuhne wrote:
> Hello Konrad,
> a happy new year and thanks for your reply.

Happy New Year as well!
> >> I know that the value has to come from hypervisor and I've seen the code
> >> in xenpm.
> > 
> > Right. Did you look in the source code from xenpm?
> I've took a look into it.
> So I've found how xenpm get the values.

Right, so it does some hypercalls to fetch that data.
> Is there code with sysfs?

I wrote some experimental that some time ago:


but looking at it I am not even sure how it would properly
write the MHz values in SysFS. It just latches it to the perf
and that is it.

> My problem is how I can create the required files in sysfs.
> Original they are created in cpufreq.c.

You are running in two problems:
 1). The cpufreq API is disabled when it boots under Xen. I did that
     so that the kernel wouldn't try to dispatch certain WRMSR which
     would be ignored by the hypervisor. This git commit 5e6262542
     has a nice description of why it was neccessary.

     You could "re-enable" the cpufreq (revert git commit 48cdd8287) and

 2). Have a new "xen" cpufreq driver. It would have to register
     itself for the cpufreq_register_governor and populate the
     policy->cpuinfo.min_freq/max_freq, min/max with the information
     that 'xenpm' would have gotten. In other words - you would need
     to shuffle parts of 'xenpm' source code in a new cpufreq
     governor driver. That by itself is not that hard (you could
     even create a thread that would do the hypercalls so often
     and just populate some internal structure with the new

     The problem is the hypercall. It is version gated on the

     42     if ( op->interface_version != XEN_SYSCTL_INTERFACE_VERSION )
     43         return -EACCES;

     which for Xen 4.3 is
     37 #define XEN_SYSCTL_INTERFACE_VERSION 0x00000009
     but for Xen 4.1 is:
     #define XEN_SYSCTL_INTERFACE_VERSION 0x00000008

     So you would have to figure out what the version is to work with
     different versions of hypervisor.

> Regards,

Hope this helps.

It might be just easier to expand the 'xenpm' code to be invoked from
your collect scripts?

> Stefan Kuhne

Xen-devel mailing list



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