| Message ID | 20090319214140.GA28868@linux-os.sc.intel.com (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
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>
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...
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.
* 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 -- 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
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 -- 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; i<perf->state_count; i++) {
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(+) -- 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