All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Cc: Len Brown <lenb@kernel.org>,
	linux-acpi <linux-acpi@vger.kernel.org>,
	mjg59@srcf.ucam.org
Subject: Re: [PATCH] ACPI: cap off P-state transition latency from buggy BIOSes
Date: Fri, 20 Mar 2009 09:17:45 +0100	[thread overview]
Message-ID: <20090320081745.GA31137@elte.hu> (raw)
In-Reply-To: <20090319214140.GA28868@linux-os.sc.intel.com>


* 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

  parent reply	other threads:[~2009-03-20  8:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-19 21:41 [PATCH] ACPI: cap off P-state transition latency from buggy BIOSes Pallipadi, Venkatesh
2009-03-19 21:47 ` Matthew Garrett
2009-03-20  3:50   ` Henrique de Moraes Holschuh
2009-03-20  4:02     ` Matthew Garrett
2009-03-20  8:17 ` Ingo Molnar [this message]
2009-03-28  1:23 ` Len Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090320081745.GA31137@elte.hu \
    --to=mingo@elte.hu \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=mjg59@srcf.ucam.org \
    --cc=venkatesh.pallipadi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.