This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] cpufreq status information

To: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Subject: RE: [Xen-devel] cpufreq status information
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Mon, 8 Sep 2008 21:50:53 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 08 Sep 2008 06:51:36 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <48C545B4.76E4.0078.0@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <48C540DC.76E4.0078.0@xxxxxxxxxx> <D470B4E54465E3469E2ABBC5AFAC390F024D9764@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <48C545B4.76E4.0078.0@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AckRt2cESeB7Cdg+RZ2lsvLyFddmmgAAeXqA
Thread-topic: [Xen-devel] cpufreq status information
>From: Jan Beulich [mailto:jbeulich@xxxxxxxxxx] 
>Sent: 2008年9月8日 21:33
>>>Trying to understand whether CPU frequency scaling is actually 
>>>working on
>>>a system currently requires (afaics) source patches, as there 
>>>is no way to
>>>get the current state of a CPU. Even if this is intentional, 
>>What do you mean by current state of CPU? If cpufreq is enabled,
>>user should be able to retrieve statistics information by sysctl
>How? I can't see where the current frequency a CPU is running at
>is being exposed.

common/sysctl.c: XEN_SYSCTL_get_pmstat

>>>this doesn't seem
>>>very helpful when considering to make this functionality available to
>>>customers: I'm certain quite a few will ask how they can tell 
>>>whether this
>>>is actually working.
>>>Now, apart from the simple job of adding a sub-hypercall to 
>>>retrieve the
>>>necessary bits, I'm wondering whether this wouldn't be just one more
>>>element that would much better be surfaced to the guest via the vCPU
>>>info structure (or, as that's size constrained, a new 
>construct to make
>>>guest-read-only information available via a shared page). Other
>>>(potential) items to make available this same way would e.g. 
>be guest-
>>>accessible last-exception-from/-to MSR values (as the values 
>read would
>>>be meaningless if read through rdmsr).
>>Not quite understand. Cpufreq is physical cpu stuff, and do you aim
>>to expose physical information through vcpu specific shared page?
>>Then that would add fixed requirement on dom0 vcpu number to
>>physical cpus, which is intentially avoided in current design.
>The intent is to expose the frequency of the pCPU the particular vCPU
>is currently running on, perhaps only in Dom0.

Then you have to pin dom0 vCPU to corresponding pCPU, and have
dom0 with same number as pCPU. I don't think such limitation
necessary for just retrieving some pCPU information.

Or if you still enable vcpu migration, you have to fake virtual freq
change notification within dom0 at vcpu migration as pCPU may 
scale its own freq individually.


Xen-devel mailing list