From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Workings/effectiveness of the xen-acpi-processor driver Date: Thu, 26 Apr 2012 11:50:33 -0400 Message-ID: <20120426155033.GE26830@phenom.dumpdata.com> References: <4F97F58A.8090409@canonical.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <4F97F58A.8090409@canonical.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefan Bader Cc: "xen-devel@lists.xensource.com" , Jan Beulich List-Id: xen-devel@lists.xenproject.org On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote: > Since there have been requests about that driver to get backported into 3.2, I > was interested to find out what or how much would be gained by that. > > The first system I tried was an AMD based one (8 core Opteron 6128@2GHz). Which > was not very successful as the drivers bail out of the init function because the > first call to acpi_processor_register_performance() returns -ENODEV. There is > some frequency scaling when running without Xen, so I need to do some more > debugging there. Did you back-port the other components - the ones that turn off the native frequency scalling? provide disable_cpufreq() function to disable the API. xen/acpi-processor: Do not depend on CPU frequency scaling drivers. xen/cpufreq: Disable the cpu frequency scaling drivers from loading > > The second system was an Intel one (4 core i7 920@2.67GHz) which was > successfully loading the driver. Via xenpm I can see the various frequencies and > also see them being changed. However the cpuidle data out of xenpm looks a bit odd: > > #> xenpm get-cpuidle-states 0 > Max C-state: C7 > > cpu id : 0 > total C-states : 2 > idle time(ms) : 10819311 > C0 : transition [00000000000000000001] > residency [00000000000000005398 ms] > C1 : transition [00000000000000000001] > residency [00000000000010819311 ms] > pc3 : [00000000000000000000 ms] > pc6 : [00000000000000000000 ms] > pc7 : [00000000000000000000 ms] > cc3 : [00000000000000000000 ms] > cc6 : [00000000000000000000 ms] > > Also gathering samples over 30s does look like only C0 and C1 are used. This Yes. > might be because C1E support is enabled in BIOS but when looking at the > intel_idle data in sysfs when running without a hypervisor will show C3 and C6 > for the cores. That could have been just a wrong output, so I plugged in a power > meter and compared a kernel running natively and running as dom0 (with and > without the acpi-processor driver). > > Native: 175W > dom0: 183W (with only marginal difference between with or without the > processor driver) > [yes, the system has a somewhat high base consumption which I attribute to a > ridiculously dimensioned graphics subsystem to be running a text console] > > This I would take as C3 and C6 really not being used and the frequency scaling To go in deeper modes there is also a need to backport a Xen unstable hypercall which will allow the kernel to detect the other states besides C0-C2. "XEN_SET_PDC query was implemented in c/s 23783: "ACPI: add _PDC input override mechanism". > having no impact on the idle system is not that much surprising. But if that was > true it would also limit the usefulness of the turbo mode which I understand > would also be limited by the c-state of the other cores. Hm, I should double-check that - but somehow I thought that Xen independetly checks for TurboMode and if the P-states are in, then they are activated. > > Do I misread the data I see? Or maybe its a known limitation? In case it is > worth doing more research I'll gladly try things and gather more data. Just missing some patches. Oh, and this one: xen/acpi: Fix Kconfig dependency on CPU_FREQ Hmm.. I think a patch disappeared somewhere. > > Thanks, > Stefan >