RE: [Xen-devel] cpufreq status information

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

>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 
>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.
>

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.)

Thanks,
Kevin

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