From patchwork Tue Apr 24 18:47:08 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stefan Bader X-Patchwork-Id: 154742 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from chlorine.canonical.com (chlorine.canonical.com [91.189.94.204]) by ozlabs.org (Postfix) with ESMTP id 43F52B6FC4 for ; Wed, 25 Apr 2012 04:47:28 +1000 (EST) Received: from localhost ([127.0.0.1] helo=chlorine.canonical.com) by chlorine.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1SMkld-0008DZ-05; Tue, 24 Apr 2012 18:47:13 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by chlorine.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1SMkla-0008DM-T1 for kernel-team@lists.ubuntu.com; Tue, 24 Apr 2012 18:47:11 +0000 Received: from p5b2e391b.dip.t-dialin.net ([91.46.57.27] helo=canonical.com) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1SMkla-00030L-Ip for kernel-team@lists.ubuntu.com; Tue, 24 Apr 2012 18:47:10 +0000 From: Stefan Bader To: kernel-team@lists.ubuntu.com Subject: Re: Xen ACPI - Precise SRU Date: Tue, 24 Apr 2012 20:47:08 +0200 Message-Id: <1335293228-21551-1-git-send-email-stefan.bader@canonical.com> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: <4F96929B.70300@canonical.com> References: <4F96929B.70300@canonical.com> X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.13 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: kernel-team-bounces@lists.ubuntu.com Errors-To: kernel-team-bounces@lists.ubuntu.com While looking into this a bit more I realized that the patch which modifies privcmd to provide a misc device interface is not needed at all to backport the cpufreq functionality. The only issues were Kconfig and Makefile in drivers/xen which could be resolved easily. So the remaining patches only make some smaller changes and add the new xen-acpi-processor driver (which only activates when in dom0). The greatly improves the unlikelyhood of regressions outside xen. It has not changed compared to before but it is simpler to see. The other modification I did was to make the xen-acpi-processor driver a built-in. It won't load outside dom0 but as a module it would require manual intervention and so its probably simpler to make it work right out of the box. So for testing: - On my usual Xen test box this does not work (only to the effect of the driver failing the acpi_processor_register_performance() call in init). Though this is not really expected (since the AMD Opteron has frequency scaling normally through powernow-k8) it does at least not make things worse. Before and after I am running at full speed. - On an Intel i7 box the driver works and I can see the frequencies changing through xenpm. Checking a Lucid and Precise HVM guest, those seem to be unaffected. Also without any visible problems was a Precise PVM guest. The only theoretical worry would be whether there is a chance the guest notices the cpu frequency changing and whether it cares if it would. - Also on the i7: I am not sure what to make of this output. For example for cpu#0 I get the following: Max C-state: C7 cpu id : 0 total C-states : 2 idle time(ms) : 3315614 C0 : transition [00000000000000000001] residency [00000000000000069798 ms] C1 : transition [00000000000000000001] residency [00000000000003315614 ms] pc3 : [00000000000000000000 ms] pc6 : [00000000000000000000 ms] pc7 : [00000000000000000000 ms] cc3 : [00000000000000000000 ms] cc6 : [00000000000000000000 ms] And gathering statistics there is also only the cpu cstates being used and the data for the socket looks like: Socket 0 PC3 0 ms 0.00% PC6 0 ms 0.00% PC7 0 ms 0.00% Core 0 CPU 0 CC3 0 ms 0.00% CC6 0 ms 0.00% Core 1 CPU 2 CC3 0 ms 0.00% CC6 0 ms 0.00% Core 2 CPU 4 CC3 0 ms 0.00% CC6 0 ms 0.00% Core 3 CPU 6 CC3 0 ms 0.00% CC6 0 ms 0.00% Again it might be not as expected but at least the same as without the change. In summary, the frequency scaling improved at least on the i5, there was no change on the AMD Opteron (which might be a bug). The C-state handling seems unaffected (which may or may not be a bug) on both. At least the results are in all cases the same or better. We could SRU the new driver now and add fixes when we get them, or wait. Probably I should try to quantify the gain by running some more tests with a (not-cking-grade) power meter attached. -Stefan The following changes since commit 7885fb139c30858f3a7d8700b44b788a5c931198: Linux 3.2.16 (2012-04-23 09:13:23 -0600) are available in the git repository at: git://kernel.ubuntu.com/smb/ubuntu-precise.git xen-acpi for you to fetch changes up to 641bfd4d37224761d5dffa5f1bec17dc6da07556: xen/cpufreq: Disable the cpu frequency scaling drivers from loading. (2012-04-24 18:54:26 +0200) ---------------------------------------------------------------- Konrad Rzeszutek Wilk (6): provide disable_cpufreq() function to disable the API. xen/acpi-processor: C and P-state driver that uploads said data to hypervisor. xen/acpi-processor: Do not depend on CPU frequency scaling drivers. xen/acpi: Fix Kconfig dependency on CPU_FREQ xen/acpi: Remove the WARN's as they just create noise. xen/cpufreq: Disable the cpu frequency scaling drivers from loading. Tim Gardner (1): UBUNTU: [Config] CONFIG_XEN_ACPI_PROCESSOR=y arch/x86/xen/setup.c | 2 + debian.master/config/config.common.ubuntu | 1 + drivers/cpufreq/cpufreq.c | 24 ++ drivers/xen/Kconfig | 17 + drivers/xen/Makefile | 2 +- drivers/xen/xen-acpi-processor.c | 562 +++++++++++++++++++++++++++++ include/linux/cpufreq.h | 2 + include/xen/interface/platform.h | 17 + 8 files changed, 626 insertions(+), 1 deletion(-) create mode 100644 drivers/xen/xen-acpi-processor.c