Re: [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes

[Keir Fraser <keir@xensource.com>]

On 30/8/07 15:45, "Langsdorf, Mark" <mark.langsdorf@amd.com> 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
this.

> 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