[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] cpufreq status information


  • To: "Jan Beulich" <jbeulich@xxxxxxxxxx>
  • 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
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • 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
>>path.
>
>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.

Thanks,
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.