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] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform

To: "Langsdorf, Mark" <mark.langsdorf@xxxxxxx>, "Tian, Kevin" <kevin.tian@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Thu, 30 Aug 2007 16:04:27 +0100
Delivery-date: Thu, 30 Aug 2007 08:05:24 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1449F58C868D8D4E9C72945771150BDF02077009@xxxxxxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acfqh8RwaTy8r4iaT0y7Njlwu+54dgAROIeQAAbzeNkACsge0AAA3oAa
Thread-topic: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes
User-agent: Microsoft-Entourage/
On 30/8/07 15:45, "Langsdorf, Mark" <mark.langsdorf@xxxxxxx> wrote:

> The advantage to doing it in the dom0 kernel is that the
> distributions have just switched from doing it in userspace,
> and thus have all their tools set up to do it in the kernel.
> To me, it makes more sense to simplify the user interface,
> so that a native mode machine and a virtual machine uses the
> same tools.  The end user shouldn't need to learn cpuspeed
> when running power management on a virtual machine host if
> the same computer uses ondemand when running a native mode
> kernel.

It's a misleading simplification. For example, the ondemand governor will
build and run in a dom0 kernel but it's not actually going to do the right
thing, as it doesn't observe whole-machine load. So, in fact, it's probably
going to close down all CPUs thinking they are idle and hence shaft system
performance. Furthermore it is very common to run a dom0 with fewer VCPUs
than PCPUs: using dom0 kernel as the control point for cpufreq disallows

> powernow-k8 and the Intel SpeedStep equivalents are being
> maintained in preference to acpi-cpufreq.  I don't think
> the code is obsolete or defunct.

I'm sure I've seen lkml posts to the contrary but I haven't been able to dig
any up. You are the powernow-k8 maintainer so I guess it's your code anyhow.
:-) But I've seen acpi-cpufreq getting beefed up with MSR support quite
recently, and most boxes support ACPI P states, so I'm surprised there
wouldn't be convergence on a single driver.

For your Xen changes, the MSR whitelisting should be conditional on actually
being on an AMD box, and also should be conditional on opt_dom0_vcpus_pin.
Actually a new config option 'cpufreq=dom0-kernel' wouldn't be a bad idea,
and that could then imply dom0_vcpus_pin. Absolutely no good can come of
letting dom0 mess with cpufreq MSRs while its VCPUS can be migrated across
cores. Also I'm not sure why you make access to the MSRs conditional on the
guest not being compat (32-on-64)?

 -- Keir

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>