Using collectd: CPUFreq in dom0

Using collectd: CPUFreq in dom0

[Stefan Kuhne]

[-- Attachment #1.1: Type: text/plain, Size: 605 bytes --]

Hello,

I've tried to get the CPUFreq plugin of collectd running in dom0.
But I mentioned that it isn't so easy to get a file in sysfs on the
rigth place.

I know that the value has to come from hypervisor and I've seen the code
in xenpm.

The only value I need is
"/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq" which would
create cpufreq.c.

Can anyone help me by giving me some hints?
I've read many websites and papers and coded many things.
I'm glade to get the sysfs file.

With "sysfs_create..." I've many trouble but "kobject_add" works fine.

Regards,
Stefan Kuhne


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 551 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Using collectd: CPUFreq in dom0

[Konrad Rzeszutek Wilk]

On Tue, Dec 25, 2012 at 07:55:37PM +0100, Stefan Kuhne wrote:
> Hello,
> 
> I've tried to get the CPUFreq plugin of collectd running in dom0.
> But I mentioned that it isn't so easy to get a file in sysfs on the
> rigth place.
> 
> 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?
> 
> The only value I need is
> "/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq" which would
> create cpufreq.c.
> 
> Can anyone help me by giving me some hints?
> I've read many websites and papers and coded many things.
> I'm glade to get the sysfs file.
> 
> With "sysfs_create..." I've many trouble but "kobject_add" works fine.
> 
> Regards,
> Stefan Kuhne
> 



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

Re: Using collectd: CPUFreq in dom0

[Stefan Kuhne]

[-- Attachment #1.1: Type: text/plain, Size: 564 bytes --]

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.

>> 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.
Is there code with sysfs?

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


Regards,
Stefan Kuhne


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 551 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Using collectd: CPUFreq in dom0

[Jan Beulich]

>>> "Stefan Kuhne" <stefan.kuhne@gmx.net> 01/04/13 10:31 PM >>>
>Am 04.01.2013 22:11, schrieb Konrad Rzeszutek Wilk:
> On Tue, Dec 25, 2012 at 07:55:37PM +0100, Stefan Kuhne wrote:
>>> 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.
>Is there code with sysfs?
>
>My problem is how I can create the required files in sysfs.
>Original they are created in cpufreq.c.

Are you aware that this cannot be done in a way directly fitting the native
case, since Dom0's vCPU-s don't match the system's pCPU-s, and hence
you'd need a separate representation, along with (where necessary, e.g.
when wanting to access MSRs like MPERF/APERF) fiddling with vCPU
affinities for obtaining/consuming the data?

Jan

Re: Using collectd: CPUFreq in dom0

[Konrad Rzeszutek Wilk]

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
> 

Re: Using collectd: CPUFreq in dom0

[Sander Eikelenboom]

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

Re: Using collectd: CPUFreq in dom0

[Konrad Rzeszutek Wilk]

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

That could also be done. I have no idea what a machine readable output would be
for this. Is this something you are volunteering to do :-)? We could always use
more patches.

Re: Using collectd: CPUFreq in dom0

[Sander Eikelenboom]

Monday, January 7, 2013, 8:13:23 PM, you wrote:

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

> That could also be done. I have no idea what a machine readable output would be
> for this. Is this something you are volunteering to do :-)? We could always use
> more patches.

I will see what i can do :-) .. but it's queued after getting vga passthrough of my ati card working to a HVM linux guest. (win7 is working)