litmus-rt.git/drivers/cpufreq/cpufreq_conservative.c, branch 2010.2

[CPUFREQ] use max load in conservative governor

2010-03-31T16:00:22+00:00

Instead of using the load of the last CPU in a package, use the
maximum load of all CPUs in a package.

Reported-by: Jean-Christian Goussard 
Signed-off-by: Dominik Brodowski 
Signed-off-by: Dave Jones

[CPUFREQ] Use global sysfs cpufreq structure for conservative governor tunings

2009-11-24T18:33:34+00:00

Same adustments that have been added to the ondemand recently.

Signed-off-by: Thomas Renninger 
Signed-off-by: Dave Jones

[CPUFREQ] Resolve time unit thinko in ondemand/conservative govs

2009-11-18T04:15:04+00:00

ondemand and conservative governors are messing up time units in the
code path where NO_HZ is not enabled and ignore_nice is set. The walltime
idletime stored is in jiffies and nice time calculation is happening in
microseconds.

The problem was reported and diagnosed by Alexander here.
http://marc.info/?l=linux-kernel&m=125752550404513&w=2

The patch below fixes this thinko.

Reported-by: Alexander Miller 
Tested-by: Alexander Miller 
Signed-off-by: Venkatesh Pallipadi 
Signed-off-by: Dave Jones

Merge branch 'percpu-for-linus' into percpu-for-next

2009-08-14T05:45:31+00:00

Conflicts:
	arch/sparc/kernel/smp_64.c
	arch/x86/kernel/cpu/perf_counter.c
	arch/x86/kernel/setup_percpu.c
	drivers/cpufreq/cpufreq_ondemand.c
	mm/percpu.c

Conflicts in core and arch percpu codes are mostly from commit
ed78e1e078dd44249f88b1dd8c76dafb39567161 which substituted many
num_possible_cpus() with nr_cpu_ids.  As for-next branch has moved all
the first chunk allocators into mm/percpu.c, the changes are moved
from arch code to mm/percpu.c.

Signed-off-by: Tejun Heo

[CPUFREQ] Fix NULL pointer dereference regression in conservative governor

2009-08-04T18:32:10+00:00

Commit ee88415caf736b89500f16e0a545614541a45005
introduced this regression when it removed enable bit in cpu_dbs_info_s.
That added a possibility of dbs_cpufreq_notifier getting called for a
CPU that is not yet managed by conservative governor. That will happen
as the transition notifier is set as soon as one CPU switches to
conservative governor and other CPUs can get a NULL pointer dereference
without the enable bit check. Add the enable bit back again.

Reported-by: Lermytte Christophe 
Signed-off-by: Venkatesh Pallipadi 
Signed-off-by: Dave Jones

[CPUFREQ] Cleanup locking in conservative governor

2009-07-07T01:38:28+00:00

Redesign the locking inside conservative driver. Make dbs_mutex handle all the
global state changes inside the driver and invent a new percpu mutex
to serialize percpu timer and frequency limit change.

Signed-off-by: Venkatesh Pallipadi 
Signed-off-by: Dave Jones

[CPUFREQ] Eliminate the recent lockdep warnings in cpufreq

2009-07-07T01:38:27+00:00

Commit b14893a62c73af0eca414cfed505b8c09efc613c although it was very
much needed to properly cleanup ondemand timer, opened-up a can of worms
related to locking dependencies in cpufreq.

Patch here defines the need for dbs_mutex and cleans up its usage in
ondemand governor. This also resolves the lockdep warnings reported here

http://lkml.indiana.edu/hypermail/linux/kernel/0906.1/01925.html
http://lkml.indiana.edu/hypermail/linux/kernel/0907.0/00820.html

and few others..

Signed-off-by: Venkatesh Pallipadi 
Signed-off-by: Dave Jones

percpu: clean up percpu variable definitions

2009-06-24T06:13:48+00:00

Percpu variable definition is about to be updated such that all percpu
symbols including the static ones must be unique.  Update percpu
variable definitions accordingly.

* as,cfq: rename ioc_count uniquely

* cpufreq: rename cpu_dbs_info uniquely

* xen: move nesting_count out of xen_evtchn_do_upcall() and rename it

* mm: move ratelimits out of balance_dirty_pages_ratelimited_nr() and
  rename it

* ipv4,6: rename cookie_scratch uniquely

* x86 perf_counter: rename prev_left to pmc_prev_left, irq_entry to
  pmc_irq_entry and nmi_entry to pmc_nmi_entry

* perf_counter: rename disable_count to perf_disable_count

* ftrace: rename test_event_disable to ftrace_test_event_disable

* kmemleak: rename test_pointer to kmemleak_test_pointer

* mce: rename next_interval to mce_next_interval

[ Impact: percpu usage cleanups, no duplicate static percpu var names ]

Signed-off-by: Tejun Heo 
Reviewed-by: Christoph Lameter 
Cc: Ivan Kokshaysky 
Cc: Jens Axboe 
Cc: Dave Jones 
Cc: Jeremy Fitzhardinge 
Cc: linux-mm 
Cc: David S. Miller 
Cc: Peter Zijlstra 
Cc: Steven Rostedt 
Cc: Li Zefan 
Cc: Catalin Marinas 
Cc: Andi Kleen

[CPUFREQ] Only set sampling_rate_max deprecated, sampling_rate_min is useful

2009-06-15T15:49:41+00:00

Update the documentation accordingly.
Cleanup and use printk_once.

Signed-off-by: Thomas Renninger 
Signed-off-by: Dave Jones

[CPUFREQ] ondemand: Uncouple minimal sampling rate from HZ in NO_HZ case

2009-06-15T15:49:41+00:00

With this patch you have following minimal sampling rate restrictions:

Kernel restrictions:
If CONFIG_NO_HZ is set, the limit is 10ms fixed.
If CONFIG_NO_HZ is not set or no_hz=off boot parameter is used, the
limits depend on the CONFIG_HZ option:
HZ=1000: min=20000us  (20ms)
HZ=250:  min=80000us  (80ms)
HZ=100:  min=200000us (200ms)

HW restrictions:
Do not sample/poll more often than HW latency * 100  exported by the low
level cpufreq HW driver

The higher value of above restrictions is the minimal sampling rate
that can be set (and can be seen via ondemand/sampling_rate_min sysfs file)

Default sampling rate still is HW latency * 1000, but this will now end
up in lower values on latest (Intel and AMD) hardware as these can switch
really fast and sampling rate mostly was limited to the 80ms or 200ms
(depending on whether HZ=250 or HZ=1000 is used).

Signed-off-by: Thomas Renninger 
Cc: Pallipadi Venkatesh 
Signed-off-by: Dave Jones