Re: cpufreq status information

[Keir Fraser <keir.fraser@eu.citrix.com>]

On 8/9/08 15:30, "Jan Beulich" <jbeulich@novell.com> wrote:

>>>> Keir Fraser <keir.fraser@eu.citrix.com> 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