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

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Monday, January 7, 2013, 4:53:17 PM, you wrote:

> 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?

Would be nice to make xenpm have a better "machine readable" output, the 
current "human readable" output is a bit hard to parse by scripts.

>> Stefan Kuhne
>> 






_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel