WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] cpufreq status information

To: Jan Beulich <jbeulich@xxxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>
Subject: Re: [Xen-devel] cpufreq status information
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Mon, 08 Sep 2008 15:35:24 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 08 Sep 2008 07:35:50 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <48C55338.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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AckRwCDkX6AT3H2zEd2nVwAX8io7RQ==
Thread-topic: [Xen-devel] cpufreq status information
User-agent: Microsoft-Entourage/11.4.0.080122
On 8/9/08 15:30, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

>>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 08.09.08 16:00 >>>
>> 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.
> 
> Right you say 'if' - what if not? How do I tell, especially when I can't touch
> the system and easily put a patched hypervisor and/or kernel on. If we
> get a complaint from a customer that he thinks frequency scaling doesn't
> do what it's expected to, we'll need to have a simple mechanism at hand
> to determine what's going on with his box.
> 
> And even for development purposes I think a one-look proof that things
> work as expected is quite useful (I'm doing the same for a few other basic
> things - the interrupt rate being one of those that helped spot problems
> that otherwise would have gone unnoticed for a much longer period of
> time).

Okay, I'll grant you that this is a useful scenario. For this purpose the
existing sysctl, plus a simple lashed-up dom0 userspace utility to dump the
statistics, would be perfectly sufficient.

Another possibility would be to generate xentrace events when CPU
frequencies change. Then, if you already buy into using xentrace to get
accurate logs about what's happening and when (which we do for our own
product development and maintenance), then the CPU frequency events would be
nicely integrated into that.

The advantage of the latter is that the frequency changes are interleaved
with other stuff you care about, like what's being scheduled, what's on run
queues etc. Since obviously frequency information all by itself is not so
interesting.

 -- Keir



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