[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] cpufreq status information

  • To: Jan Beulich <jbeulich@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Mon, 08 Sep 2008 14:38:41 +0100
  • Cc:
  • Delivery-date: Mon, 08 Sep 2008 06:39:12 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AckRuDSLc08lnH2rEd2nVwAX8io7RQ==
  • Thread-topic: [Xen-devel] cpufreq status information

On 8/9/08 14:12, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> Trying to understand whether CPU frequency scaling is actually working on
> a system currently requires (afaics) source patches, as there is no way to
> get the current state of a CPU. Even if this is intentional, this doesn't seem
> very helpful when considering to make this functionality available to
> customers: I'm certain quite a few will ask how they can tell whether this
> is actually working.

Well, they might notice that their battery lasts longer than an hour. :-)

> So I'm basically considering to add a generic mechanism first, and then
> make cpufreq the first user of it. The question just is - use a completely
> new (guest-ro) per-vCPU page, perhaps with chained descriptors rather
> than a fixed layout, or extend the vCPU info structure, but e.g. require
> the guest to use VCPUOP_register_vcpu_info to gain access to all
> structure fields.

I'm skeptical about throwing in more shared-memory structures between Xen
and guests anyway. It doesn't even seem a good fit here since this info is
not of great interest to most guests in my opinion. I presume most users'
curiosities will be satisfied by being able to poll CPU frequencies/voltages
from dom0 via a hypercall.

 -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.