aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/cpufreq
Commit message (Collapse)AuthorAgeFilesLines
* [PATCH] cpufreq: make the transition_notifier chain use SRCUAlan Stern2006-10-041-7/+13
| | | | | | | | | | | | | | | | | | | | | | This patch (as762) changes the cpufreq_transition_notifier_list from a blocking_notifier_head to an srcu_notifier_head. This will prevent errors caused attempting to call down_read() to access the notifier chain at a time when interrupts must remain disabled, during system suspend. It's not clear to me whether this is really necessary; perhaps the chain could be made into an atomic_notifier. However a couple of the callout routines do use blocking operations, so this approach seems safer. The head of the notifier chain needs to be initialized before use; this is done by an __init routine at core_initcall time. If this turns out not to be a good choice, it can easily be changed. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: "Paul E. McKenney" <paulmck@us.ibm.com> Cc: Jesse Brandeburg <jesse.brandeburg@gmail.com> Cc: Dave Jones <davej@codemonkey.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [CPUFREQ] Fix cut-n-paste bug in suspend printkDave Jones2006-09-261-1/+1
| | | | Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] Fix some more CPU hotplug locking.Dave Jones2006-09-221-2/+0
| | | | | | | | | | | | | | | | | | | | | | | Lukewarm IQ detected in hotplug locking BUG: warning at kernel/cpu.c:38/lock_cpu_hotplug() [<b0134a42>] lock_cpu_hotplug+0x42/0x65 [<b02f8af1>] cpufreq_update_policy+0x25/0xad [<b0358756>] kprobe_flush_task+0x18/0x40 [<b0355aab>] schedule+0x63f/0x68b [<b01377c2>] __link_module+0x0/0x1f [<b0119e7d>] __cond_resched+0x16/0x34 [<b03560bf>] cond_resched+0x26/0x31 [<b0355b0e>] wait_for_completion+0x17/0xb1 [<f965c547>] cpufreq_stat_cpu_callback+0x13/0x20 [cpufreq_stats] [<f9670074>] cpufreq_stats_init+0x74/0x8b [cpufreq_stats] [<b0137872>] sys_init_module+0x91/0x174 [<b0102c81>] sysenter_past_esp+0x56/0x79 As there are other places that call cpufreq_update_policy without the hotplug lock, it seems better to keep the hotplug locking at the lower level for the time being until this is revamped. Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] Fix sparse warning in ondemandDave Jones2006-09-051-1/+1
| | | | | | drivers/cpufreq/cpufreq_ondemand.c:323:2: warning: Using plain integer as NULL pointer Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] make drivers/cpufreq/cpufreq_ondemand.c:powersave_bias_target() staticAdrian Bunk2006-08-141-2/+3
| | | | | | | This patch makes the needlessly global powersave_bias_target() static. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ][2/2] ondemand: updated add powersave_bias tunableAlexey Starikovskiy2006-08-111-17/+140
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ondemand selects the minimum frequency that can retire a workload with negligible idle time -- ideally resulting in the highest performance/power efficiency with negligible performance impact. But on some systems and some workloads, this algorithm is more performance biased than necessary, and de-tuning it a bit to allow some performance impact can save measurable power. This patch adds a "powersave_bias" tunable to ondemand to allow it to reduce its target frequency by a specified percent. By default, the powersave_bias is 0 and has no effect. powersave_bias is in units of 0.1%, so it has an effective range of 1 through 1000, resulting in 0.1% to 100% impact. In practice, users will not be able to detect a difference between 0.1% increments, but 1.0% increments turned out to be too large. Also, the max value of 1000 (100%) would simply peg the system in its deepest power saving P-state, unless the processor really has a hardware P-state at 0Hz:-) For example, If ondemand requests 2.0GHz based on utilization, and powersave_bias=100, this code will knock 10% off the target and seek a target of 1.8GHz instead of 2.0GHz until the next sampling. If 1.8 is an exact match with an hardware frequency we use it, otherwise we average our time between the frequency next higher than 1.8 and next lower than 1.8. Note that a user or administrative program can change powersave_bias at run-time depending on how they expect the system to be used. Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi at intel.com> Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy at intel.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ][1/2] ondemand: updated tune for hardware coordinationAlexey Starikovskiy2006-08-111-5/+8
| | | | | | | | | Try to make dbs_check_cpu() call on all CPUs at the same jiffy. This will help when multiple cores share P-states via Hardware Coordination. Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi at intel.com> Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy at intel.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] Fix typo.Dave Jones2006-08-111-1/+1
| | | | Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] [2/2] demand load governor modules.Jeremy Fitzhardinge2006-07-311-0/+17
| | | | | | | Demand-load cpufreq governor modules if needed. Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] [1/2] add __find_governor helper and clean up some error handling.Jeremy Fitzhardinge2006-07-311-23/+34
| | | | | | | | | Adds a __find_governor() helper function to look up a governor by name. Also restructures some error handling to conform to the "single-exit" model which is generally preferred for kernel code. Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] return error when failing to set minfreqMattia Dongili2006-07-311-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I just stumbled on this bug/feature, this is how to reproduce it: # echo 450000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq # echo 450000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq # echo powersave > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor # cpufreq-info -p 450000 450000 powersave # echo 1800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq ; echo $? 0 # cpufreq-info -p 450000 450000 powersave Here it is. The kernel refuses to set a min_freq higher than the max_freq but it allows a max_freq lower than min_freq (lowering min_freq also). This behaviour is pretty straightforward (but undocumented) and it doesn't return an error altough failing to accomplish the requested action (set min_freq). The problem (IMO) is basically that userspace is not allowed to set a full policy atomically while the kernel always does that thus it must enforce an ordering on operations. The attached patch returns -EINVAL if trying to increase frequencies starting from scaling_min_freq and documents the correct ordering of writes. Signed-off-by: Mattia Dongili <malattia@linux.it> Signed-off-by: Dominik Brodowski <linux at dominikbrodowski.net> Signed-off-by: Dave Jones <davej@redhat.com> --
* [PATCH] Reorganize the cpufreq cpu hotplug locking to not be totally bizareArjan van de Ven2006-07-264-26/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [cpufreq] ondemand: make shutdown sequence more robustLinus Torvalds2006-07-231-6/+10
| | | | | | | | | | | Shutting down the ondemand policy was fraught with potential problems, causing issues for SMP suspend (which wants to hot- unplug) all but the last CPU. This should fix at least the worst problems (divide-by-zero and infinite wait for the workqueue to shut down). Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Fix cpufreq vs hotplug lockdep recursion.Dave Jones2006-07-071-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | [ There's some not quite baked bits in cpufreq-git right now so sending this on as a patch instead ] On Thu, 2006-07-06 at 07:58 -0700, Tom London wrote: > After installing .2356 I get this each time I boot: > ======================================================= > [ INFO: possible circular locking dependency detected ] > ------------------------------------------------------- > S06cpuspeed/1620 is trying to acquire lock: > (dbs_mutex){--..}, at: [<c060d6bb>] mutex_lock+0x21/0x24 > > but task is already holding lock: > (cpucontrol){--..}, at: [<c060d6bb>] mutex_lock+0x21/0x24 > > which lock already depends on the new lock. > make sure the cpu hotplug recursive mutex (yuck) is taken early in the cpufreq codepaths to avoid a AB-BA deadlock. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Merge master.kernel.org:/pub/scm/linux/kernel/git/davej/cpufreqLinus Torvalds2006-07-041-169/+91
|\ | | | | | | | | | | | | | | | | * master.kernel.org:/pub/scm/linux/kernel/git/davej/cpufreq: Move workqueue exports to where the functions are defined. [CPUFREQ] Misc cleanups in ondemand. [CPUFREQ] Make ondemand sampling per CPU and remove the mutex usage in sampling path. [CPUFREQ] Add queue_delayed_work_on() interface for workqueues. [CPUFREQ] Remove slowdown from ondemand sampling path.
| * [CPUFREQ] Misc cleanups in ondemand.Venkatesh Pallipadi2006-06-301-31/+19
| | | | | | | | | | | | | | | | | | Misc cleanups in ondemand. Should have zero functional impact. Also adding Alexey as author. Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Dave Jones <davej@redhat.com>
| * [CPUFREQ] Make ondemand sampling per CPU and remove the mutex usage in ↵Venkatesh Pallipadi2006-06-301-40/+32
| | | | | | | | | | | | | | | | | | | | sampling path. Make ondemand sampling per CPU and remove the mutex usage in sampling path. Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Dave Jones <davej@redhat.com>
| * [CPUFREQ] Remove slowdown from ondemand sampling path.Venkatesh Pallipadi2006-06-301-98/+40
| | | | | | | | | | | | | | | | | | | | | | Remove slowdown from ondemand sampling path. This reduces the code path length in dbs_check_cpu() by half. slowdown was not used by ondemand by default. If there are any user level tools that were using this tunable, they may report error now. Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Dave Jones <davej@redhat.com>
* | Remove obsolete #include <linux/config.h>Jörn Engel2006-06-303-3/+0
|/ | | | | Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
* [PATCH] cpu hotplug: make cpu_notifier related notifier blocks __cpuinit onlyChandra Seetharaman2006-06-271-1/+1
| | | | | | | | | | | | Make notifier_blocks associated with cpu_notifier as __cpuinitdata. __cpuinitdata makes sure that the data is init time only unless CONFIG_HOTPLUG_CPU is defined. Signed-off-by: Chandra Seetharaman <sekharan@us.ibm.com> Cc: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] cpu hotplug: make [un]register_cpu_notifier init time onlyChandra Seetharaman2006-06-272-5/+7
| | | | | | | | | | | | | | | | CPUs come online only at init time (unless CONFIG_HOTPLUG_CPU is defined). So, cpu_notifier functionality need to be available only at init time. This patch makes register_cpu_notifier() available only at init time, unless CONFIG_HOTPLUG_CPU is defined. This patch exports register_cpu_notifier() and unregister_cpu_notifier() only if CONFIG_HOTPLUG_CPU is defined. Signed-off-by: Chandra Seetharaman <sekharan@us.ibm.com> Cc: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] cpu hotplug: revert init patch submitted for 2.6.17Chandra Seetharaman2006-06-271-1/+1
| | | | | | | | | | | | | | | | | | | | | In 2.6.17, there was a problem with cpu_notifiers and XFS. I provided a band-aid solution to solve that problem. In the process, i undid all the changes you both were making to ensure that these notifiers were available only at init time (unless CONFIG_HOTPLUG_CPU is defined). We deferred the real fix to 2.6.18. Here is a set of patches that fixes the XFS problem cleanly and makes the cpu notifiers available only at init time (unless CONFIG_HOTPLUG_CPU is defined). If CONFIG_HOTPLUG_CPU is defined then cpu notifiers are available at run time. This patch reverts the notifier_call changes made in 2.6.17 Signed-off-by: Chandra Seetharaman <sekharan@us.ibm.com> Cc: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] cpufreq build fixAndrew Morton2006-06-232-0/+2
| | | | | | | | | | | | | 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: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [CPUFREQ] Fix ondemand vs suspend deadlockVenkatesh Pallipadi2006-06-212-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] cpufreq core {d,}printk adjustmentsJan Beulich2006-06-041-4/+4
| | | | | | | Remove KERN_* suffixes from some cpufreq driver's dprintk-s. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] Remove more freq_table reinitialisations.Dave Jones2006-05-301-4/+8
| | | | Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] Fix another redundant initialisation in freq_tableDave Jones2006-05-301-1/+1
| | | | Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] Remove duplicate assignment in freq_tableDave Jones2006-05-301-1/+1
| | | | Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] CodingStyle nits in cpufreq_stats.cDave Jones2006-05-301-3/+3
| | | | Signed-off-by: Dave Jones <davej@redhat.com>
* [PATCH] x86_64: Move ondemand timer into own work queueAndi Kleen2006-05-081-8/+20
| | | | | | | | | | | | | | | | Taking the cpu hotplug semaphore in a normal events workqueue is unsafe because other tasks can wait for any workqueues with it hold. This results in a deadlock. Move the DBS timer into its own work queue which is not affected by other work queue flushes to avoid this. Has been acked by Venkatesh. Cc: venkatesh.pallipadi@intel.com Cc: cpufreq@lists.linux.org.uk Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Remove __devinit and __cpuinit from notifier_call definitionsChandra Seetharaman2006-04-261-1/+1
| | | | | | | | | | | | | Few of the notifier_chain_register() callers use __init in the definition of notifier_call. It is incorrect as the function definition should be available after the initializations (they do not unregister them during initializations). This patch fixes all such usages to _not_ have the notifier_call __init section. Signed-off-by: Chandra Seetharaman <sekharan@us.ibm.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [CPUFREQ] drivers/cpufreq/cpufreq.c: static functions mustn't be exportedAdrian Bunk2006-04-181-1/+0
| | | | | | | This patch removes the EXPORT_SYMBOL_GPL of the static function cpufreq_parse_governor(). Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] If max_freq got reduced (e.g. by _PPC) a write to sysfs ↵Thomas Renninger2006-04-181-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | scaling_governor let cpufreq core stuck at low max_freq for ever The previous patch had bugs (locking and refcount). This one could also be related to the latest DELL reports. But they only slip into this if a user prog (e.g. powersave daemon does when AC got (un) plugged due to a scheme change) echos something to /sys/../cpufreq/scaling_governor while the frequencies got limited by BIOS. This one works: Subject: Max freq stucks at low freq if reduced by _PPC and sysfs gov access The problem is reproducable by(if machine is limiting freqs via BIOS): - Unplugging AC -> max freq gets limited - echo ${governor} >/sys/.../cpufreq/scaling_governor (policy->user_data.max gets overridden with policy->max and will never come up again.) This patch exchanged the cpufreq_set_policy call to __cpufreq_set_policy and duplicated it's functionality but did not override user_data.max. The same happens with overridding min/max values. If freqs are limited and you override the min freq value, the max freq global value will also get stuck to the limited freq, even if BIOS allows all freqs again. Last scenario does only happen if BIOS does not reduce the frequency to the lowest value (should never happen, just for correctness...) drivers/cpufreq/cpufreq.c | 17 +++++++++++++++-- 1 files changed, 15 insertions(+), 2 deletions(-) Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] Update LART site URLErik Mouw2006-04-031-1/+1
| | | | | | | | | | Update LART site URL. The LART website moved to http://www.lartmaker.nl/. This patch updates the URL in CpuFreq specific files. Signed-off-by: Erik Mouw <erik@bitwizard.nl> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] Remove pointless check in conservative governor.Dave Jones2006-04-011-4/+2
| | | | | | < 0 checks on unsigned variables are pointless. Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] trailing whitespace removal de-jour.Dave Jones2006-03-291-3/+2
| | | | Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] extra debugging in cpufreq_add_dev()Dave Jones2006-03-291-1/+1
| | | | | Snipped from an otherwise rejected patch by Jan Beulich <jbeulich@novell.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] cpufreq_conservative: keep ignore_nice_load and freq_step values ↵Mattia Dongili2006-03-281-2/+2
| | | | | | | | | | when reselected Keep the value of ignore_nice_load and freq_step of the conservative governor after the governor is deselected and reselected. Signed-off-by: Mattia Dongili <malattia@linux.it> Signed-off-by: Dave Jones <davej@redhat.com>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/brodo/cpufreq-2.6Dave Jones2006-03-272-91/+71
|\
| * [PATCH] cpufreq_ondemand: add range checkDominik Brodowski2006-03-261-0/+3
| | | | | | | | | | | | | | Assert that cpufreq_target is, at least, called with the minimum frequency allowed by this policy, not something lower. It triggered problems on ARM. Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
| * [PATCH] cpufreq_ondemand: keep ignore_nice_load value when it is reselectedEric Piel2006-03-261-2/+1
| | | | | | | | | | | | | | | | | | | | | | Keep the value of ignore_nice_load of the ondemand governor even after the governor has been deselected and selected back. This is the behavior of the other exported values of the ondemand governor and it's much more user-friendly. Signed-off-by: Eric Piel <eric.piel@tremplin-utc.net> Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
| * [PATCH] cpufreq_ondemand: Warn if it cannot run due to too long transition ↵Eric Piel2006-03-261-1/+4
| | | | | | | | | | | | | | | | | | | | | | latency Display a warning if the ondemand governor can not be selected due to a transition latency of the cpufreq driver which is too long. Signed-off-by: Eric Piel <eric.piel@tremplin-utc.net> Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
| * [PATCH] cpufreq_conservative: alternative initialise approachAlexander Clouter2006-03-261-37/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | 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: Alexander Clouter <alex-kernel@digriz.org.uk> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
| * [PATCH] cpufreq_conservative: make for_each_cpu() safeAlexander Clouter2006-03-261-49/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Alexander Clouter <alex-kernel@digriz.org.uk> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
| * [PATCH] cpufreq_conservative: alter default responsivenessAlexander Clouter2006-03-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | 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: Alexander Clouter <alex-kernel@digriz.org.uk> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
| * [PATCH] cpufreq_conservative: aligning of codebase with ondemandAlexander Clouter2006-03-261-26/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Alexander Clouter <alex-kernel@digriz.org.uk> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
* | [PATCH] Notifier chain update: API changesAlan Stern2006-03-271-35/+26
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The kernel's implementation of notifier chains is unsafe. There is no protection against entries being added to or removed from a chain while the chain is in use. The issues were discussed in this thread: http://marc.theaimsgroup.com/?l=linux-kernel&m=113018709002036&w=2 We noticed that notifier chains in the kernel fall into two basic usage classes: "Blocking" chains are always called from a process context and the callout routines are allowed to sleep; "Atomic" chains can be called from an atomic context and the callout routines are not allowed to sleep. We decided to codify this distinction and make it part of the API. Therefore this set of patches introduces three new, parallel APIs: one for blocking notifiers, one for atomic notifiers, and one for "raw" notifiers (which is really just the old API under a new name). New kinds of data structures are used for the heads of the chains, and new routines are defined for registration, unregistration, and calling a chain. The three APIs are explained in include/linux/notifier.h and their implementation is in kernel/sys.c. With atomic and blocking chains, the implementation guarantees that the chain links will not be corrupted and that chain callers will not get messed up by entries being added or removed. For raw chains the implementation provides no guarantees at all; users of this API must provide their own protections. (The idea was that situations may come up where the assumptions of the atomic and blocking APIs are not appropriate, so it should be possible for users to handle these things in their own way.) There are some limitations, which should not be too hard to live with. For atomic/blocking chains, registration and unregistration must always be done in a process context since the chain is protected by a mutex/rwsem. Also, a callout routine for a non-raw chain must not try to register or unregister entries on its own chain. (This did happen in a couple of places and the code had to be changed to avoid it.) Since atomic chains may be called from within an NMI handler, they cannot use spinlocks for synchronization. Instead we use RCU. The overhead falls almost entirely in the unregister routine, which is okay since unregistration is much less frequent that calling a chain. Here is the list of chains that we adjusted and their classifications. None of them use the raw API, so for the moment it is only a placeholder. ATOMIC CHAINS ------------- arch/i386/kernel/traps.c: i386die_chain arch/ia64/kernel/traps.c: ia64die_chain arch/powerpc/kernel/traps.c: powerpc_die_chain arch/sparc64/kernel/traps.c: sparc64die_chain arch/x86_64/kernel/traps.c: die_chain drivers/char/ipmi/ipmi_si_intf.c: xaction_notifier_list kernel/panic.c: panic_notifier_list kernel/profile.c: task_free_notifier net/bluetooth/hci_core.c: hci_notifier net/ipv4/netfilter/ip_conntrack_core.c: ip_conntrack_chain net/ipv4/netfilter/ip_conntrack_core.c: ip_conntrack_expect_chain net/ipv6/addrconf.c: inet6addr_chain net/netfilter/nf_conntrack_core.c: nf_conntrack_chain net/netfilter/nf_conntrack_core.c: nf_conntrack_expect_chain net/netlink/af_netlink.c: netlink_chain BLOCKING CHAINS --------------- arch/powerpc/platforms/pseries/reconfig.c: pSeries_reconfig_chain arch/s390/kernel/process.c: idle_chain arch/x86_64/kernel/process.c idle_notifier drivers/base/memory.c: memory_chain drivers/cpufreq/cpufreq.c cpufreq_policy_notifier_list drivers/cpufreq/cpufreq.c cpufreq_transition_notifier_list drivers/macintosh/adb.c: adb_client_list drivers/macintosh/via-pmu.c sleep_notifier_list drivers/macintosh/via-pmu68k.c sleep_notifier_list drivers/macintosh/windfarm_core.c wf_client_list drivers/usb/core/notify.c usb_notifier_list drivers/video/fbmem.c fb_notifier_list kernel/cpu.c cpu_chain kernel/module.c module_notify_list kernel/profile.c munmap_notifier kernel/profile.c task_exit_notifier kernel/sys.c reboot_notifier_list net/core/dev.c netdev_chain net/decnet/dn_dev.c: dnaddr_chain net/ipv4/devinet.c: inetaddr_chain It's possible that some of these classifications are wrong. If they are, please let us know or submit a patch to fix them. Note that any chain that gets called very frequently should be atomic, because the rwsem read-locking used for blocking chains is very likely to incur cache misses on SMP systems. (However, if the chain's callout routines may sleep then the chain cannot be atomic.) The patch set was written by Alan Stern and Chandra Seetharaman, incorporating material written by Keith Owens and suggestions from Paul McKenney and Andrew Morton. [jes@sgi.com: restructure the notifier chain initialization macros] Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Chandra Seetharaman <sekharan@us.ibm.com> Signed-off-by: Jes Sorensen <jes@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] cpufreq: fix section mismatch warningsSam Ravnborg2006-03-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cpufreq are the only remaining bit to be solved for me to have a modpost clean build for sparc64 - so I took one more look at it. changelog entry: Fix section mismatch warnings in cpufreq: WARNING: drivers/cpufreq/cpufreq_stats.o - Section mismatch: reference to .init.text: from .data between 'cpufreq_stat_cpu_notifier' (at offset 0xa8) and 'notifier_policy_block' WARNING: drivers/cpufreq/cpufreq_stats.o - Section mismatch: reference to .init.text: from .exit.text after 'cleanup_module' (at offset 0x30) The culprint is the function: cpufreq_stat_cpu_callback It is marked __cpuinit which get's redefined to __init in case HOTPLUG_CPU is not enabled as per. init.h: #ifdef CONFIG_HOTPLUG_CPU #define __cpuinit #else #define __cpuinit __init #endif $> grep HOTPLUG .config CONFIG_HOTPLUG=y But cpufreq_stat_cpu_callback() is used in: __exit cpufreq_stats_exit() static struct notifier_block cpufreq_stat_cpu_notifier cpufreq_stat_cpu_notifier is again used in: __init cpufreq_stats_init() __exit cpufreq_stats_exit() So in both cases used from both __init and __exit context. Only solution seems to drop __cpuinit tag. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] Fix handling for CPU hotplugDave Jones2006-03-051-2/+49
| | | | | | | | | | | | This patch adds proper logic to cpufreq driver in order to handle CPU Hotplug. When CPUs go on/offline, the affected CPUs data, cpufreq_policy->cpus, is not updated properly. This causes sysfs directories and symlinks to be in an incorrect state after few CPU on/offlines. Signed-off-by: Jacob Shin <jacob.shin@amd.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] Lots of whitespace & CodingStyle cleanup.Dave Jones2006-02-287-88/+86
| | | | Signed-off-by: Dave Jones <davej@redhat.com>
generated by cgit v1.1 at 2024-11-01 06:28:35 +0000