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 22:42:15 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 08 Sep 2008 07:42:47 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <48C5519A.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> <D470B4E54465E3469E2ABBC5AFAC390F024D9765@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <48C5519A.76E4.0078.0@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AckRvniIoszNS/jeRBKIeYU9cHskcAAAL4Tw
Thread-topic: [Xen-devel] cpufreq status information
>From: Jan Beulich [mailto:jbeulich@xxxxxxxxxx] 
>Sent: 2008年9月8日 22:24
>>>> "Tian, Kevin" <kevin.tian@xxxxxxxxx> 08.09.08 15:50 >>>
>>>From: Jan Beulich [mailto:jbeulich@xxxxxxxxxx] 
>>>How? I can't see where the current frequency a CPU is running at
>>>is being exposed.
>>common/sysctl.c: XEN_SYSCTL_get_pmstat
>Ah, okay, I missed that. But - I can't use this from the kernel anyway,
>and tools that track the frequency (i.e. KDE sysguard) would need to
>be modified in order to make use of this. I'd really prefer 
>to correctly reflect this at least in Dom0. And even beyond 
>that - I can't
>seem to find any users of the APIs in tools/libxc/xc_pm.c, so these
>really appear to be dead stubs.

They're not dead stubs, and we have internal tools as a modified 
xen PowerTop version and future we can expect more. This is not
a cpufreq only design choice, and similar thing goes for other stuff
like MCA and CPU hotplug: whether we want to reuse all existing
dom0 Linux interfaces (which however pushes requirement on a
vcpu placement within dom0 for each pcpu), or we use some side-
band hypercall with existing tools supporting Xen hypercall interface
to retrieve pcpu related information in a batch. By far we choose the
latter for cpufreq.

Actually even by keeping same interface, existing dom0 tools may 
have to be modified more or less for specific physical information 
as those tools haven't system knowledge. For example, PowerTop 
uses /proc/interrupts to derive break events for Cx residency, which 
however only reflects virtual interrupts within dom0.

Even for /proc/cpuinfo, then you finally require a mangled version
with mixed physical and virtual bits?

>>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.
>Why? All I care about is a snapshot value. It doesn't matter whether
>it's stale by the time I get it, there's nothing going to be calculated
>from it, apart from statistics.

Then such physical info may conflict with other code snippet, if 
existing in guest, which simply gets freq info from some self 
calibrated logic. If we can't assure a consistent view about freq
within guest, what's the point then?


Xen-devel mailing list