From patchwork Thu Feb 19 17:07:41 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nick Piggin X-Patchwork-Id: 23435 X-Patchwork-Delegate: benh@kernel.crashing.org Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from ozlabs.org (localhost [127.0.0.1]) by ozlabs.org (Postfix) with ESMTP id 4E3EADDE20 for ; Fri, 20 Feb 2009 04:11:41 +1100 (EST) X-Original-To: linuxppc-dev@ozlabs.org Delivered-To: linuxppc-dev@ozlabs.org Received: from mx1.suse.de (cantor.suse.de [195.135.220.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx1.suse.de", Issuer "CAcert Class 3 Root" (verified OK)) by ozlabs.org (Postfix) with ESMTPS id 1EC14DDE0F for ; Fri, 20 Feb 2009 04:07:51 +1100 (EST) Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 3AAAA45657; Thu, 19 Feb 2009 18:07:44 +0100 (CET) Date: Thu, 19 Feb 2009 18:07:41 +0100 From: Nick Piggin To: benh@kernel.crashing.org, paulus@samba.org, linuxppc-dev@ozlabs.org Subject: [patch] powerpc: estimate G5 cpufreq transition latency Message-ID: <20090219170741.GI1747@wotan.suse.de> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.9i X-BeenThere: linuxppc-dev@ozlabs.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@ozlabs.org Errors-To: linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@ozlabs.org Setting G5's cpu frequency transition latency to CPUFREQ_ETERNAL stops ondemand governor from working. I measured the latency using sched_clock and haven't seen much higher than 11000ns, so I set this to 12000ns for my configuration. Possibly other configurations will be different? Ideally the generic code would be able to measure it in case the platform does not provide it. But this simple patch at least makes it throttle again. Signed-off-by: Nick Piggin Index: linux-2.6/arch/powerpc/platforms/powermac/cpufreq_64.c =================================================================== --- linux-2.6.orig/arch/powerpc/platforms/powermac/cpufreq_64.c 2009-02-20 01:42:41.000000000 +1100 +++ linux-2.6/arch/powerpc/platforms/powermac/cpufreq_64.c 2009-02-20 01:50:15.000000000 +1100 @@ -86,6 +86,7 @@ static DEFINE_MUTEX(g5_switch_mutex); +static unsigned long transition_latency; #ifdef CONFIG_PMAC_SMU @@ -357,7 +358,7 @@ static int g5_cpufreq_cpu_init(struct cpufreq_policy *policy) { - policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL; + policy->cpuinfo.transition_latency = transition_latency; policy->cur = g5_cpu_freqs[g5_query_freq()].frequency; /* secondary CPUs are tied to the primary one by the * cpufreq core if in the secondary policy we tell it that @@ -500,6 +501,7 @@ g5_cpu_freqs[1].frequency = max_freq/2; /* Set callbacks */ + transition_latency = 12000; g5_switch_freq = g5_scom_switch_freq; g5_query_freq = g5_scom_query_freq; freq_method = "SCOM"; @@ -675,6 +677,7 @@ g5_cpu_freqs[1].frequency = min_freq; /* Set callbacks */ + transition_latency = CPUFREQ_ETERNAL; g5_switch_volt = g5_pfunc_switch_volt; g5_switch_freq = g5_pfunc_switch_freq; g5_query_freq = g5_pfunc_query_freq; Index: linux-2.6/drivers/cpufreq/cpufreq.c =================================================================== --- linux-2.6.orig/drivers/cpufreq/cpufreq.c 2009-02-20 01:42:43.000000000 +1100 +++ linux-2.6/drivers/cpufreq/cpufreq.c 2009-02-20 01:50:15.000000000 +1100 @@ -1559,9 +1559,11 @@ else { printk(KERN_WARNING "%s governor failed, too long" " transition latency of HW, fallback" - " to %s governor\n", + " to %s governor (latency=%lld max=%lld)\n", policy->governor->name, - gov->name); + gov->name, + policy->cpuinfo.transition_latency, + policy->governor->max_transition_latency); policy->governor = gov; } }