Re: Using collectd: CPUFreq in dom0

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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:

http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/stable/cpufreq-xen.v6

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
     values).

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


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

     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
>