Messages in this thread Patch in this message | | | From | "Peter Oruba" <> | Subject | [PATCH] bugfix cpufreq in combination with performance governor | Date | Mon, 4 Jun 2007 18:56:23 +0200 |
| |
Am Dienstag, 29. Mai 2007 18:20:06 schrieb Peter Oruba: > Am Dienstag, 29. Mai 2007 18:06:21 schrieben Sie: > > On Tue, May 29, 2007 at 03:47:00PM +0200, Peter Oruba wrote: > > > Dave, > > > > > > I am contacting you regarding a frequency scaling issue that I encountered with the performance governor in combination with CPU hotplug. In cpufreq.c CPU frequency is reduced to its > > > minimum before the CPU gets unregistered and set offline. Does that have a particular reason? Since the (k8-)governor does not monitor CPU frequency that setting also applies then to the remaining CPU > > > as well and lets the system run on the lowest frequency although performance is chose as the policy. > > > > > > --- > > > static int cpufreq_cpu_callback(struct notifier_block *nfb, > > > unsigned long action, void *hcpu) > > > { > > > > > > [......] > > > > > > case CPU_DOWN_PREPARE_FROZEN: > > > if (unlikely(lock_policy_rwsem_write(cpu))) > > > BUG(); > > > > > > policy = cpufreq_cpu_data[cpu]; > > > if (policy) { > > > __cpufreq_driver_target(policy, policy->min, > > > CPUFREQ_RELATION_H); > > > } > > > __cpufreq_remove_dev(sys_dev); > > > > This is the path taken when we call suspend. > > To be honest, I doubt that reducing the speed has any benefit at all, > > as we're about to put the CPU to sleep anyway. > > > > (btw, in future sending questions to cpufreq@lists.linux.org.uk is a better > > idea. The subsystem is sufficiently complex that at times, others can > > answer questions better than I can, especially with the various > > implementations all being subtley different). > > > > Thanks, > > > > Dave > > > Okay, removing the __cpufreq_driver_target call would solve would obviously solve that problem (which btw also exists on Core2, as I tested a couple of minutes ago). Is it planned to be changed > in the near future? > > Thanks, > Peter > My patch, aimed at that issue.
Signed-off by: Peter Oruba <peter.oruba@amd.com>
--- --- cpufreq/drivers/cpufreq/cpufreq.c.orig 2007-06-04 18:30:57.000000000 +0200 +++ cpufreq/drivers/cpufreq/cpufreq.c 2007-06-04 18:43:01.000000000 +0200 @@ -1698,11 +1698,6 @@ static int cpufreq_cpu_callback(struct n if (unlikely(lock_policy_rwsem_write(cpu))) BUG();
- policy = cpufreq_cpu_data[cpu]; - if (policy) { - __cpufreq_driver_target(policy, policy->min, - CPUFREQ_RELATION_H); - } __cpufreq_remove_dev(sys_dev); break; case CPU_DOWN_FAILED: --- -- AMD Saxony Limited Liability Company & Co. KG Operating System Research Center Wilschdorfer Landstr. 101, 01109 Dresden, Germany Register Court Dresden: HRA 4896 General Partner authorized to represent: AMD Saxony LLC (Wilmington, Delaware, US) General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |