RE: [Xen-devel] cpufreq status information

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>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 
>/proc/cpuinfo
>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?

Thanks,
Kevin 

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