ACPI: cap off P-state transition latency from buggy BIOSes
authorPallipadi, Venkatesh <venkatesh.pallipadi@intel.com>
Tue, 7 Apr 2009 03:53:45 +0000 (23:53 -0400)
committerChris Wright <chrisw@sous-sol.org>
Mon, 27 Apr 2009 17:36:52 +0000 (10:36 -0700)
commitd930ec7bcd0c4ef7ce0e555fbd540c5ebcedc8bd
tree5f1f28e8937f90120087c0984c6c1e3e70653b7a
parent32626208c6548358e28b0857ad030b8a3fa12d86
ACPI: cap off P-state transition latency from buggy BIOSes

upstream commit: a59d1637eb0e0a37ee0e5c92800c60abe3624e24

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.

mjg: We've confirmed that this also helps on the X31

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Acked-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c