From patchwork Thu Mar 19 21:41:40 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: venkip X-Patchwork-Id: 13161 Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n2JLfmqi024638 for ; Thu, 19 Mar 2009 21:41:48 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753274AbZCSVls (ORCPT ); Thu, 19 Mar 2009 17:41:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756665AbZCSVls (ORCPT ); Thu, 19 Mar 2009 17:41:48 -0400 Received: from mga11.intel.com ([192.55.52.93]:19570 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753274AbZCSVls (ORCPT ); Thu, 19 Mar 2009 17:41:48 -0400 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 19 Mar 2009 14:38:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,391,1233561600"; d="scan'208";a="440386496" Received: from linux-os.sc.intel.com ([172.25.110.8]) by fmsmga002.fm.intel.com with ESMTP; 19 Mar 2009 14:37:09 -0700 Received: by linux-os.sc.intel.com (Postfix, from userid 47009) id B428E28006; Thu, 19 Mar 2009 14:41:40 -0700 (PDT) Date: Thu, 19 Mar 2009 14:41:40 -0700 From: "Pallipadi, Venkatesh" To: Len Brown Cc: linux-acpi , mjg59@srcf.ucam.org Subject: [PATCH] ACPI: cap off P-state transition latency from buggy BIOSes Message-ID: <20090319214140.GA28868@linux-os.sc.intel.com> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org Some BIOSes report very high frequency transition latency which are plainly wrong on CPus that can change frequency using native MSR interface. One such system is IBM T42 (2327-8ZU) as reported by Owen Taylor and Rik van Riel. cpufreq_ondemand driver uses this transition latency to come up with a reasonable sampling interval to sample CPU usage and with such high latency value, ondemand sampling interval ends up being very high (0.5 sec, in this particular case), resulting in performance impact due to slow response to increasing frequency. Fix it by capping-off the transition latency to 20uS for native MSR based frequency transitions. Signed-off-by: Venkatesh Pallipadi Acked-by: Matthew Garrett --- arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Index: linux-2.6/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c 2008-05-02 09:45:23.000000000 -0700 +++ linux-2.6/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c 2008-06-30 12:08:32.000000000 -0700 @@ -659,6 +659,18 @@ static int acpi_cpufreq_cpu_init(struct perf->states[i].transition_latency * 1000; } + /* Check for high latency (>20uS) from buggy BIOSes, like on T42 */ + if (perf->control_register.space_id == ACPI_ADR_SPACE_FIXED_HARDWARE && + policy->cpuinfo.transition_latency > 20 * 1000) { + static int print_once; + policy->cpuinfo.transition_latency = 20 * 1000; + if (!print_once) { + print_once = 1; + printk(KERN_INFO "Capping off P-state tranision latency" + " at 20 uS\n"); + } + } + data->max_freq = perf->states[0].core_frequency * 1000; /* table init */ for (i=0; istate_count; i++) {