From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes Date: Thu, 30 Aug 2007 16:04:27 +0100 Message-ID: References: <1449F58C868D8D4E9C72945771150BDF02077009@SAUSEXMB1.amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1449F58C868D8D4E9C72945771150BDF02077009@SAUSEXMB1.amd.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Langsdorf, Mark" , "Tian, Kevin" , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 30/8/07 15:45, "Langsdorf, Mark" 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