From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: cpufreq status information Date: Mon, 08 Sep 2008 15:00:47 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Tian, Kevin" , Jan Beulich Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 8/9/08 14:50, "Tian, Kevin" 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 arbitrary 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. -- Keir