From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Using collectd: CPUFreq in dom0 Date: Mon, 7 Jan 2013 10:53:17 -0500 Message-ID: <20130107155317.GG3219@phenom.dumpdata.com> References: <50D9F6A9.8030008@access.denied> <20130104211143.GA7996@phenom.dumpdata.com> <50E749B5.3020003@access.denied> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <50E749B5.3020003@access.denied> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefan Kuhne Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org 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 >