linux-kernel - [PATCH] bugfix cpufreq in combination with performance governor

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>] [day] [month] [year] [list]

Message-ID: <200706041856.23594.peter.oruba@amd.com>
Date:	Mon, 4 Jun 2007 18:56:23 +0200
From:	"Peter Oruba" <peter.oruba@....com>
To:	cpufreq@...ts.linux.org.uk
cc:	"Linux List" <linux-kernel@...r.kernel.org>
Subject: [PATCH] bugfix cpufreq in combination with performance governor

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@...ts.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@....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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/