[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes
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 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |