linux-kernel - Re: [patch 013/100] ACPI: cap off P-state transition latency from buggy BIOSes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sat, 25 Apr 2009 17:59:02 +0200
From:	Martin Steigerwald <Martin@...htvoll.de>
To:	linux-kernel@...r.kernel.org
Cc:	Chris Wright <chrisw@...s-sol.org>, stable@...nel.org,
	Justin Forbes <jmforbes@...uxtx.org>,
	Zwane Mwaikambo <zwane@....linux.org.uk>,
	"Theodore Ts'o" <tytso@....edu>,
	Randy Dunlap <rdunlap@...otime.net>,
	Dave Jones <davej@...hat.com>,
	Chuck Wolber <chuckw@...ntumlinux.com>,
	Chris Wedgwood <reviews@...cw.f00f.org>,
	Michael Krufky <mkrufky@...uxtv.org>,
	Chuck Ebbert <cebbert@...hat.com>,
	Domenico Andreoli <cavokz@...il.com>, Willy Tarreau <w@....eu>,
	Rodrigo Rubira Branco <rbranco@...checkpoint.com>,
	Jake Edge <jake@....net>, Eugene Teo <eteo@...hat.com>,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	alan@...rguk.ukuu.org.uk, Len Brown <lenb@...nel.org>,
	linux-acpi@...r.kernel.org,
	Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>,
	Matthew Garrett <mjg@...hat.com>,
	Len Brown <len.brown@...el.com>
Subject: Re: [patch 013/100] ACPI: cap off P-state transition latency from buggy BIOSes

Am Donnerstag 23 April 2009 schrieb Chris Wright:
> -stable review patch.  If anyone has any objections, please let us
> know. ---------------------
>
> From: Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>
>
> 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@...el.com>
> Acked-by: Matthew Garrett <mjg@...hat.com>
> Signed-off-by: Len Brown <len.brown@...el.com>
> Signed-off-by: Chris Wright <chrisw@...s-sol.org>
> ---
>
>  arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c |   12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> --- a/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
> +++ b/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
> @@ -680,6 +680,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"

typo: tranision => transition

> +				" at 20 uS\n");
> +		}
> +	}
> +
>  	data->max_freq = perf->states[0].core_frequency * 1000;
>  	/* table init */
>  	for (i=0; i<perf->state_count; i++) {
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Download attachment "signature.asc " of type "application/pgp-signature" (198 bytes)