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:49:25 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 08 Sep 2008 07:49:50 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C4EAF6BC.26E6B%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: <48C55338.76E4.0078.0@xxxxxxxxxx> <C4EAF6BC.26E6B%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AckRwCDkX6AT3H2zEd2nVwAX8io7RQAAW87w
Thread-topic: [Xen-devel] cpufreq status information
>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] 
>Sent: 2008年9月8日 22:35
>> 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 
>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

Yes, we already have many examples within dom0 to retrieve xen
specific information bypassing dom0. By the way, we have the plan
to add xentrace events for all processor PM stuff, including freq
change and also cpu idle states transition (like break causes, etc.)


Xen-devel mailing list