[PATCH] ACPI: cap off P-state transition latency from buggy BIOSes

[PATCH] ACPI: cap off P-state transition latency from buggy BIOSes

[Pallipadi, Venkatesh]

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 <venkatesh.pallipadi@intel.com>

---
 arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)

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; i<perf->state_count; i++) {

Re: [PATCH] ACPI: cap off P-state transition latency from buggy BIOSes

[Matthew Garrett]

On Thu, Mar 19, 2009 at 02:41:40PM -0700, Pallipadi, Venkatesh wrote:

> Fix it by capping-off the transition latency to 20uS for native MSR based
> frequency transitions.
> 
> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>

We've confirmed that this also helps on the X31.

Acked-by: Matthew Garrett <mjg@redhat.com>

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] ACPI: cap off P-state transition latency from buggy BIOSes

[Henrique de Moraes Holschuh]

On Thu, 19 Mar 2009, Matthew Garrett wrote:
> On Thu, Mar 19, 2009 at 02:41:40PM -0700, Pallipadi, Venkatesh wrote:
> > Fix it by capping-off the transition latency to 20uS for native MSR based
> > frequency transitions.
> > 
> > Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
> 
> We've confirmed that this also helps on the X31.
> 
> Acked-by: Matthew Garrett <mjg@redhat.com>

Any chance of sending this to -stable after it hits mainline?  It is the
sort of stuff a huge number of thinkpad users will want in their kernels
ASAP...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [PATCH] ACPI: cap off P-state transition latency from buggy BIOSes

[Matthew Garrett]

On Fri, Mar 20, 2009 at 12:50:16AM -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 19 Mar 2009, Matthew Garrett wrote:
> > On Thu, Mar 19, 2009 at 02:41:40PM -0700, Pallipadi, Venkatesh wrote:
> > > Fix it by capping-off the transition latency to 20uS for native MSR based
> > > frequency transitions.
> > > 
> > > Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
> > 
> > We've confirmed that this also helps on the X31.
> > 
> > Acked-by: Matthew Garrett <mjg@redhat.com>
> 
> Any chance of sending this to -stable after it hits mainline?  It is the
> sort of stuff a huge number of thinkpad users will want in their kernels
> ASAP...

I don't see why not.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] ACPI: cap off P-state transition latency from buggy BIOSes

[Ingo Molnar]

* Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com> wrote:

> 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 <venkatesh.pallipadi@intel.com>
> 
> ---
>  arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c |   12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> 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");
> +		}

btw.., in the next merge window we'll have printk_once():

   f036be9: printk: introduce printk_once()

so then the above can be cleaned up to:

> +	/* 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) {
> +
> +		policy->cpuinfo.transition_latency = 20 * 1000;
> +		printk_once(KERN_INFO
> +		    "Capping off P-state tranision latency at 20 uS\n");
> +	}

	Ingo

Re: [PATCH] ACPI: cap off P-state transition latency from buggy BIOSes

[Len Brown]

On Thu, 19 Mar 2009, Pallipadi, Venkatesh wrote:

> 
> 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 <venkatesh.pallipadi@intel.com>
> 
> ---
>  arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c |   12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> 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; i<perf->state_count; i++) {
> --

Sort of makes you wonder if Windows is using this bogus info, or 
ignoring it...

applied.

thanks,
Len Brown, Intel Open Source Technology Center