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: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>, "Jan Beulich" <jbeulich@xxxxxxxxxx>
Subject: RE: [Xen-devel] cpufreq status information
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Mon, 8 Sep 2008 22:13:00 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 08 Sep 2008 07:13:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C4EAEE9F.26E60%keir.fraser@xxxxxxxxxxxxx>
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: <D470B4E54465E3469E2ABBC5AFAC390F024D9765@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C4EAEE9F.26E60%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AckRt2cESeB7Cdg+RZ2lsvLyFddmmgAAeXqAAAB/fisAAE+A8A==
Thread-topic: [Xen-devel] cpufreq status information
>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] 
>Sent: 2008年9月8日 22:01
>On 8/9/08 14:50, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>>> 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.
>Greater virtualisation of cpufreq info (making it available to 
>guests, with pcpu->vcpu remapping) is just not very useful in 
>my opinion.
>It's one of those features that more hacker-ish users might 
>think they want
>to decorate their desktop.


>After all, guest performance is at least as affected by CPU (and other
>resources) contention from other guests as it is by power-management
>governors in the hyeprvisor. Indeed, if the governors are 
>doing their job
>right then guest performance should not be considerably 
>impacted by them
>even in absolute terms.

Exactly. :-)


Xen-devel mailing list