1. 07 7月, 2009 2 次提交
  2. 15 6月, 2009 2 次提交
  3. 27 5月, 2009 1 次提交
    • M
      [CPUFREQ] fix timer teardown in conservative governor · b253d2b2
      Mathieu Desnoyers 提交于
      * Rafael J. Wysocki (rjw@sisk.pl) wrote:
      > This message has been generated automatically as a part of a report
      > of regressions introduced between 2.6.28 and 2.6.29.
      >
      > The following bug entry is on the current list of known regressions
      > introduced between 2.6.28 and 2.6.29.  Please verify if it still should
      > be listed and let me know (either way).
      >
      >
      > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13186
      > Subject		: cpufreq timer teardown problem
      > Submitter	: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      > Date		: 2009-04-23 14:00 (24 days old)
      > References	: http://marc.info/?l=linux-kernel&m=124049523515036&w=4
      > Handled-By	: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      > Patch		: http://patchwork.kernel.org/patch/19754/
      > 		  http://patchwork.kernel.org/patch/19753/
      >
      
      (re-send with updated changelog)
      
      cpufreq fix timer teardown in conservative governor
      
      The problem is that dbs_timer_exit() uses cancel_delayed_work() when it should
      use cancel_delayed_work_sync(). cancel_delayed_work() does not wait for the
      workqueue handler to exit.
      
      The ondemand governor does not seem to be affected because the
      "if (!dbs_info->enable)" check at the beginning of the workqueue handler returns
      immediately without rescheduling the work. The conservative governor in
      2.6.30-rc has the same check as the ondemand governor, which makes things
      usually run smoothly. However, if the governor is quickly stopped and then
      started, this could lead to the following race :
      
      dbs_enable could be reenabled and multiple do_dbs_timer handlers would run.
      This is why a synchronized teardown is required.
      
      Depends on patch
      cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call
      
      The following patch applies to 2.6.30-rc2. Stable kernels have a similar
      issue which should also be fixed, but the code changed between 2.6.29
      and 2.6.30, so this patch only applies to 2.6.30-rc.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      CC: Andrew Morton <akpm@linux-foundation.org>
      CC: gregkh@suse.de
      CC: stable@kernel.org
      CC: cpufreq@vger.kernel.org
      CC: Ingo Molnar <mingo@elte.hu>
      CC: rjw@sisk.pl
      CC: Ben Slusky <sluskyb@paranoiacs.org>
      Signed-off-by: NDave Jones <davej@redhat.com>
      b253d2b2
  4. 25 2月, 2009 7 次提交
  5. 06 1月, 2009 1 次提交
  6. 10 10月, 2008 2 次提交
    • S
      [CPUFREQ] Don't export governors for default governor · c4d14bc0
      Sven Wegener 提交于
      We don't need to export the governors for use as the default governor,
      because the default governor will be built-in anyway and we can access
      the symbol directly.
      
      This also fixes the following sparse warnings:
      
      drivers/cpufreq/cpufreq_conservative.c:578:25: warning: symbol 'cpufreq_gov_conservative' was not declared. Should it be static?
      drivers/cpufreq/cpufreq_ondemand.c:582:25: warning: symbol 'cpufreq_gov_ondemand' was not declared. Should it be static?
      drivers/cpufreq/cpufreq_performance.c:39:25: warning: symbol 'cpufreq_gov_performance' was not declared. Should it be static?
      drivers/cpufreq/cpufreq_powersave.c:38:25: warning: symbol 'cpufreq_gov_powersave' was not declared. Should it be static?
      drivers/cpufreq/cpufreq_userspace.c:190:25: warning: symbol 'cpufreq_gov_userspace' was not declared. Should it be static?
      Signed-off-by: NSven Wegener <sven.wegener@stealer.net>
      Signed-off-by: NDave Jones <davej@redhat.com>
      c4d14bc0
    • B
      [CPUFREQ] use deferrable delayed work init in conservative governor · 8217e4f4
      Ben Slusky 提交于
      Venki Pallipadi made a similar change to the ondemand governor a while
      back (in commit 28287033). It seems to
      work just as well in the conservative governor, leading to fewer wakeups
      as reported by powertop.
      Signed-off-by: NBen Slusky <sluskyb@paranoiacs.org>
      Signed-off-by: NDave Jones <davej@redhat.com>
      8217e4f4
  7. 09 8月, 2008 1 次提交
  8. 24 5月, 2008 1 次提交
  9. 18 1月, 2008 1 次提交
    • J
      cpufreq: Initialise default governor before use · 6915719b
      Johannes Weiner 提交于
      When the cpufreq driver starts up at boot time, it calls into the default
      governor which might not be initialised yet.  This hurts when the
      governor's worker function relies on memory that is not yet set up by its
      init function.
      
      This migrates all governors from module_init() to fs_initcall() when being
      the default, as was already done in cpufreq_performance when it was the
      only possible choice.  The performance governor is always initialized early
      because it might be used as fallback even when not being the default.
      
      Fixes at least one actual oops where ondemand is the default governor and
      cpufreq_governor_dbs() uses the uninitialised kondemand_wq work-queue
      during boot-time.
      Signed-off-by: NJohannes Weiner <hannes@saeurebad.de>
      Cc: Dave Jones <davej@codemonkey.org.uk>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6915719b
  10. 23 10月, 2007 2 次提交
  11. 05 10月, 2007 1 次提交
    • T
      [CPUFREQ] allow ondemand and conservative cpufreq governors to be used as default · 1c256245
      Thomas Renninger 提交于
      Depending on the transition latency of the HW for cpufreq switches, the
      ondemand or conservative governor cannot be used with certain cpufreq
      drivers.  Still the ondemand should be the default governor on a wide range
      of systems.  This patch allows this and lets the governor fallback to the
      performance governor at cpufreq driver load time, if the driver does not
      support fast enough frequency switching.
      
      Main benefit is that on e.g.  installation or other systems without
      userspace support a working dynamic cpufreq support can be achieved on most
      systems by simply loading the cpufreq driver.  This is especially essential
      for recent x86(_64) laptop hardware which may rely on working dynamic
      cpufreq OS support.
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Bryan Wu <bryan.wu@analog.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDave Jones <davej@redhat.com>
      1c256245
  12. 15 2月, 2007 1 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      Tim Schmielau 提交于
      After Al Viro (finally) succeeded in removing the sched.h #include in module.h
      recently, it makes sense again to remove other superfluous sched.h includes.
      There are quite a lot of files which include it but don't actually need
      anything defined in there.  Presumably these includes were once needed for
      macros that used to live in sched.h, but moved to other header files in the
      course of cleaning it up.
      
      To ease the pain, this time I did not fiddle with any header files and only
      removed #includes from .c-files, which tend to cause less trouble.
      
      Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
      arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
      allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
      configs in arch/arm/configs on arm.  I also checked that no new warnings were
      introduced by the patch (actually, some warnings are removed that were emitted
      by unnecessarily included header files).
      Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a
  13. 11 2月, 2007 1 次提交
  14. 22 11月, 2006 1 次提交
  15. 07 11月, 2006 1 次提交
  16. 21 10月, 2006 1 次提交
  17. 26 7月, 2006 1 次提交
    • A
      [PATCH] Reorganize the cpufreq cpu hotplug locking to not be totally bizare · 153d7f3f
      Arjan van de Ven 提交于
      The patch below moves the cpu hotplugging higher up in the cpufreq
      layering; this is needed to avoid recursive taking of the cpu hotplug
      lock and to otherwise detangle the mess.
      
      The new rules are:
      1. you must do lock_cpu_hotplug() around the following functions:
         __cpufreq_driver_target
         __cpufreq_governor (for CPUFREQ_GOV_LIMITS operation only)
         __cpufreq_set_policy
      2. governer methods (.governer) must NOT take the lock_cpu_hotplug()
         lock in any way; they are called with the lock taken already
      3. if your governer spawns a thread that does things, like calling
         __cpufreq_driver_target, your thread must honor rule #1.
      4. the policy lock and other cpufreq internal locks nest within
         the lock_cpu_hotplug() lock.
      
      I'm not entirely happy about how the __cpufreq_governor rule ended up
      (conditional locking rule depending on the argument) but basically all
      callers pass this as a constant so it's not too horrible.
      
      The patch also removes the cpufreq_governor() function since during the
      locking audit it turned out to be entirely unused (so no need to fix it)
      
      The patch works on my testbox, but it could use more testing
      (otoh... it can't be much worse than the current code)
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      153d7f3f
  18. 23 6月, 2006 1 次提交
    • A
      [PATCH] cpufreq build fix · 138a0128
      Andrew Morton 提交于
      drivers/cpufreq/cpufreq_ondemand.c: In function 'do_dbs_timer':
      drivers/cpufreq/cpufreq_ondemand.c:374: warning: implicit declaration of function 'lock_cpu_hotplug'
      drivers/cpufreq/cpufreq_ondemand.c:381: warning: implicit declaration of function 'unlock_cpu_hotplug'
      drivers/cpufreq/cpufreq_conservative.c: In function 'do_dbs_timer':
      drivers/cpufreq/cpufreq_conservative.c:425: warning: implicit declaration of function 'lock_cpu_hotplug'
      drivers/cpufreq/cpufreq_conservative.c:432: warning: implicit declaration of function 'unlock_cpu_hotplug'
      
      Cc: Dave Jones <davej@codemonkey.org.uk>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      138a0128
  19. 22 6月, 2006 1 次提交
    • V
      [CPUFREQ] Fix ondemand vs suspend deadlock · 4ec223d0
      Venkatesh Pallipadi 提交于
      Rootcaused the bug to a deadlock in cpufreq and ondemand. Due to non-existent
      ordering between cpu_hotplug lock and dbs_mutex. Basically a race condition
      between cpu_down() and do_dbs_timer().
      
      cpu_down() flow:
      * cpu_down() call for CPU 1
      * Takes hot plug lock
      * Calls pre down notifier
      *     cpufreq notifier handler calls cpufreq_driver_target() which takes
            cpu_hotplug lock again. OK as cpu_hotplug lock is recursive in same
            process context
      * CPU 1 goes down
      * Calls post down notifier
      *     cpufreq notifier handler calls ondemand event stop which takes dbs_mutex
      
      So, cpu_hotplug lock is taken before dbs_mutex in this flow.
      
      do_dbs_timer is triggerred by a periodic timer event.
      It first takes dbs_mutex and then takes cpu_hotplug lock in
      cpufreq_driver_target().
      Note the reverse order here compared to above. So, if this timer event happens
      at right moment during cpu_down, system will deadlok.
      
      Attached patch fixes the issue for both ondemand and conservative.
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      4ec223d0
  20. 02 4月, 2006 1 次提交
  21. 29 3月, 2006 1 次提交
  22. 26 3月, 2006 4 次提交
    • A
      [PATCH] cpufreq_conservative: alternative initialise approach · a159b827
      Alexander Clouter 提交于
      Venki, author of cpufreq_ondemand, came up with a neater way to remove the
      initialiser code from the main loop of my code and out to the point when the
      governor is actually initialised.
      
      Not only does it look but it also feels cleaner, plus its simpler to
      understand.  It also saves a bunch of pointless conditional statements in the
      main loop.
      Signed-off-by: NAlexander Clouter <alex-kernel@digriz.org.uk>
      Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>
      a159b827
    • A
      [PATCH] cpufreq_conservative: make for_each_cpu() safe · 08a28e2e
      Alexander Clouter 提交于
      All these changes should make cpufreq_conservative safe in regards to the x86
      for_each_cpu cpumask.h changes and whatnot.
      
      Whilst making it safe a number of pointless for loops related to the cpu
      mask's were removed.  I was never comfortable with all those for loops,
      especially as the iteration is over the same data again and again for each
      CPU you had in a single poll, an O(n^2) outcome to frequency scaling.
      
      The approach I use is to assume by default no CPU's exist and it sets the
      requested_freq to zero as a kind of flag, the reasoning is in the source ;)
      If the CPU is queried and requested_freq is zero then it initialises the
      variable to current_freq and then continues as if nothing happened which
      should be the same net effect as before?
      Signed-off-by: NAlexander Clouter <alex-kernel@digriz.org.uk>
      Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>
      08a28e2e
    • A
      [PATCH] cpufreq_conservative: alter default responsiveness · e8a02572
      Alexander Clouter 提交于
      The sensible approach to making conservative less responsive than ondemand :)
      As mentioned in patch [1/4].  We do not want conservative to shoot through
      all the frequencies, its point (by default) is to slowly move through them.
      
      By default its ten times less responsive.
      Signed-off-by: NAlexander Clouter <alex-kernel@digriz.org.uk>
      Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>
      e8a02572
    • A
      [PATCH] cpufreq_conservative: aligning of codebase with ondemand · 2c906b31
      Alexander Clouter 提交于
      Since the conservative govenor was released its codebase has drifted from the
      the direction and updates that have been applied to the ondemand govornor.
      
      This patch addresses the lack of updates in that period and brings
      conservative back up to date.  The resulting diff file between
      cpufreq_ondemand.c and cpufreq_conservative.c is now much smaller and shows
      more clearly the differences between the two.
      
      Another reason to do this is ages ago, knowingly, I did a piss poor attempt
      at making conservative less responsive by knocking up
      DEF_SAMPLING_RATE_LATENCY_MULTIPLIER by two orders of magnitude.  I did fix
      this ages ago but in my dis-organisation I must have toasted the diff and
      left it the way it was.  About two weeks ago a user contacted me saying he
      was having problems with the conservative governor with his AMD Athlon XP-M
      2800+ as /sys/devices/system/cpu/cpu0/cpufreq/conservative showed
        sampling_rate_min   9950000
        sampling_rate_max   1360065408
      
      Nine seconds to decide about changing the frequency....not too responsive :)
      Signed-off-by: NAlexander Clouter <alex-kernel@digriz.org.uk>
      Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>
      2c906b31
  23. 19 1月, 2006 1 次提交
  24. 01 12月, 2005 1 次提交
    • A
      [PATCH] cpufreq_conservative/ondemand: invert meaning of 'ignore nice' · 001893cd
      Alexander Clouter 提交于
      The use of the 'ignore_nice' sysfs file is confusing to anyone using it.
      This removes the sysfs file 'ignore_nice' and in its place creates a
      'ignore_nice_load' entry that defaults to '0'; meaning nice'd processes
      _are_ counted towards the 'business' calculation.
      
      WARNING: this obvious breaks any userland tools that expected ignore_nice'
      to exist, to draw attention to this fact it was concluded on the mailing
      list that the entry should be removed altogether so the userland app breaks
      and so the author can build simple to detect workaround.  Having said that
      it seems currently very few tools even make use of this functionality; all
      I could find was a Gentoo Wiki entry.
      Signed-off-by: NAlexander Clouter <alex-kernel@digriz.org.uk>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NDave Jones <davej@redhat.com>
      001893cd
  25. 28 10月, 2005 1 次提交
  26. 01 6月, 2005 2 次提交