2005-04-16 16:20:36 -06:00
|
|
|
/*
|
|
|
|
* drivers/cpufreq/cpufreq_ondemand.c
|
|
|
|
*
|
|
|
|
* Copyright (C) 2001 Russell King
|
|
|
|
* (C) 2003 Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>.
|
|
|
|
* Jun Nakajima <jun.nakajima@intel.com>
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License version 2 as
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/cpufreq.h>
|
2006-06-23 04:31:19 -06:00
|
|
|
#include <linux/cpu.h>
|
2005-04-16 16:20:36 -06:00
|
|
|
#include <linux/jiffies.h>
|
|
|
|
#include <linux/kernel_stat.h>
|
2006-01-13 16:54:22 -07:00
|
|
|
#include <linux/mutex.h>
|
2008-08-04 12:59:12 -06:00
|
|
|
#include <linux/hrtimer.h>
|
|
|
|
#include <linux/tick.h>
|
|
|
|
#include <linux/ktime.h>
|
2009-02-04 03:54:04 -07:00
|
|
|
#include <linux/sched.h>
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
/*
|
|
|
|
* dbs is used in this file as a shortform for demandbased switching
|
|
|
|
* It helps to keep variable names smaller, simpler
|
|
|
|
*/
|
|
|
|
|
2008-08-04 12:59:10 -06:00
|
|
|
#define DEF_FREQUENCY_DOWN_DIFFERENTIAL (10)
|
2005-04-16 16:20:36 -06:00
|
|
|
#define DEF_FREQUENCY_UP_THRESHOLD (80)
|
2010-10-06 14:54:24 -06:00
|
|
|
#define DEF_SAMPLING_DOWN_FACTOR (1)
|
|
|
|
#define MAX_SAMPLING_DOWN_FACTOR (100000)
|
2008-08-04 12:59:12 -06:00
|
|
|
#define MICRO_FREQUENCY_DOWN_DIFFERENTIAL (3)
|
|
|
|
#define MICRO_FREQUENCY_UP_THRESHOLD (95)
|
2009-04-22 05:48:29 -06:00
|
|
|
#define MICRO_FREQUENCY_MIN_SAMPLE_RATE (10000)
|
2005-05-31 20:03:50 -06:00
|
|
|
#define MIN_FREQUENCY_UP_THRESHOLD (11)
|
2005-04-16 16:20:36 -06:00
|
|
|
#define MAX_FREQUENCY_UP_THRESHOLD (100)
|
|
|
|
|
2006-02-27 22:43:23 -07:00
|
|
|
/*
|
|
|
|
* The polling frequency of this governor depends on the capability of
|
2005-04-16 16:20:36 -06:00
|
|
|
* the processor. Default polling frequency is 1000 times the transition
|
2006-02-27 22:43:23 -07:00
|
|
|
* latency of the processor. The governor will work on any processor with
|
|
|
|
* transition latency <= 10mS, using appropriate sampling
|
2005-04-16 16:20:36 -06:00
|
|
|
* rate.
|
|
|
|
* For CPUs with transition latency > 10mS (mostly drivers with CPUFREQ_ETERNAL)
|
|
|
|
* this governor will not work.
|
|
|
|
* All times here are in uS.
|
|
|
|
*/
|
[CPUFREQ] Avoid the ondemand cpufreq governor to use a too high frequency for stats.
The problem is in the ondemand governor, there is a periodic measurement
of the CPU usage. This CPU usage is updated by the scheduler after every
tick (basically, by adding 1 either to "idle" or to "user" or to
"system"). So if the frequency of the governor is too high, the stat
will be meaningless (as mostly no number have changed).
So this patch checks that the measurements are separated by at least 10
ticks. It means that by default, stats will have about 5% error (20
ticks). Of course those numbers can be argued but, IMHO, they look sane.
The patch also includes a small clean-up to check more explictly the
result of the conversion from ns to µs being null.
Let's note that (on x86) this has never been really needed before 2.6.13
because HZ was always 1000. Now that HZ can be 100, some CPU might be
affected by this problem. For instance when HZ=100, the centrino ,which
has a 10µs transition latency, would lead to the governor allowing to
read stats every tick (10ms)!
Signed-off-by: Eric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Dave Jones <davej@redhat.com>
2005-09-20 13:39:35 -06:00
|
|
|
#define MIN_SAMPLING_RATE_RATIO (2)
|
2009-02-04 03:55:12 -07:00
|
|
|
|
2009-04-22 05:48:29 -06:00
|
|
|
static unsigned int min_sampling_rate;
|
|
|
|
|
2009-02-04 03:55:12 -07:00
|
|
|
#define LATENCY_MULTIPLIER (1000)
|
2009-04-22 05:48:29 -06:00
|
|
|
#define MIN_LATENCY_MULTIPLIER (100)
|
2007-10-02 14:28:12 -06:00
|
|
|
#define TRANSITION_LATENCY_LIMIT (10 * 1000 * 1000)
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2006-11-22 07:57:56 -07:00
|
|
|
static void do_dbs_timer(struct work_struct *work);
|
2009-07-24 07:25:06 -06:00
|
|
|
static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
|
|
|
|
unsigned int event);
|
|
|
|
|
|
|
|
#ifndef CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
|
|
|
|
static
|
|
|
|
#endif
|
|
|
|
struct cpufreq_governor cpufreq_gov_ondemand = {
|
|
|
|
.name = "ondemand",
|
|
|
|
.governor = cpufreq_governor_dbs,
|
|
|
|
.max_transition_latency = TRANSITION_LATENCY_LIMIT,
|
|
|
|
.owner = THIS_MODULE,
|
|
|
|
};
|
2006-11-22 07:57:56 -07:00
|
|
|
|
|
|
|
/* Sampling types */
|
2007-02-05 17:12:44 -07:00
|
|
|
enum {DBS_NORMAL_SAMPLE, DBS_SUB_SAMPLE};
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
struct cpu_dbs_info_s {
|
2006-06-28 14:49:52 -06:00
|
|
|
cputime64_t prev_cpu_idle;
|
ondemand: Solve a big performance issue by counting IOWAIT time as busy
The ondemand cpufreq governor uses CPU busy time (e.g. not-idle
time) as a measure for scaling the CPU frequency up or down.
If the CPU is busy, the CPU frequency scales up, if it's idle,
the CPU frequency scales down. Effectively, it uses the CPU busy
time as proxy variable for the more nebulous "how critical is
performance right now" question.
This algorithm falls flat on its face in the light of workloads
where you're alternatingly disk and CPU bound, such as the ever
popular "git grep", but also things like startup of programs and
maildir using email clients... much to the chagarin of Andrew
Morton.
This patch changes the ondemand algorithm to count iowait time
as busy, not idle, time. As shown in the breakdown cases above,
iowait is performance critical often, and by counting iowait,
the proxy variable becomes a more accurate representation of the
"how critical is performance" question.
The problem and fix are both verified with the "perf timechar"
tool.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dave Jones <davej@redhat.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <20100509082606.3d9f00d0@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-05-09 09:26:06 -06:00
|
|
|
cputime64_t prev_cpu_iowait;
|
2006-06-28 14:49:52 -06:00
|
|
|
cputime64_t prev_cpu_wall;
|
2008-08-04 12:59:12 -06:00
|
|
|
cputime64_t prev_cpu_nice;
|
2006-02-27 22:43:23 -07:00
|
|
|
struct cpufreq_policy *cur_policy;
|
2009-01-17 23:43:44 -07:00
|
|
|
struct delayed_work work;
|
[CPUFREQ][2/2] ondemand: updated add powersave_bias tunable
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>
2006-07-31 12:28:12 -06:00
|
|
|
struct cpufreq_frequency_table *freq_table;
|
|
|
|
unsigned int freq_lo;
|
|
|
|
unsigned int freq_lo_jiffies;
|
|
|
|
unsigned int freq_hi_jiffies;
|
2010-10-06 14:54:24 -06:00
|
|
|
unsigned int rate_mult;
|
2007-02-05 17:12:44 -07:00
|
|
|
int cpu;
|
2009-07-02 18:08:32 -06:00
|
|
|
unsigned int sample_type:1;
|
|
|
|
/*
|
|
|
|
* percpu mutex that serializes governor limit change with
|
|
|
|
* do_dbs_timer invocation. We do not want do_dbs_timer to run
|
|
|
|
* when user is changing the governor or limits.
|
|
|
|
*/
|
|
|
|
struct mutex timer_mutex;
|
2005-04-16 16:20:36 -06:00
|
|
|
};
|
2009-06-24 00:13:48 -06:00
|
|
|
static DEFINE_PER_CPU(struct cpu_dbs_info_s, od_cpu_dbs_info);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
static unsigned int dbs_enable; /* number of CPUs using this policy */
|
|
|
|
|
2006-06-21 16:18:34 -06:00
|
|
|
/*
|
2011-03-03 13:31:27 -07:00
|
|
|
* dbs_mutex protects dbs_enable in governor start/stop.
|
2006-06-21 16:18:34 -06:00
|
|
|
*/
|
2006-06-28 14:52:18 -06:00
|
|
|
static DEFINE_MUTEX(dbs_mutex);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
[CPUFREQ][2/2] ondemand: updated add powersave_bias tunable
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>
2006-07-31 12:28:12 -06:00
|
|
|
static struct dbs_tuners {
|
2006-02-27 22:43:23 -07:00
|
|
|
unsigned int sampling_rate;
|
|
|
|
unsigned int up_threshold;
|
2008-08-04 12:59:10 -06:00
|
|
|
unsigned int down_differential;
|
2006-02-27 22:43:23 -07:00
|
|
|
unsigned int ignore_nice;
|
2010-10-06 14:54:24 -06:00
|
|
|
unsigned int sampling_down_factor;
|
[CPUFREQ][2/2] ondemand: updated add powersave_bias tunable
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>
2006-07-31 12:28:12 -06:00
|
|
|
unsigned int powersave_bias;
|
2010-05-09 09:26:51 -06:00
|
|
|
unsigned int io_is_busy;
|
[CPUFREQ][2/2] ondemand: updated add powersave_bias tunable
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>
2006-07-31 12:28:12 -06:00
|
|
|
} dbs_tuners_ins = {
|
2006-02-27 22:43:23 -07:00
|
|
|
.up_threshold = DEF_FREQUENCY_UP_THRESHOLD,
|
2010-10-06 14:54:24 -06:00
|
|
|
.sampling_down_factor = DEF_SAMPLING_DOWN_FACTOR,
|
2008-08-04 12:59:10 -06:00
|
|
|
.down_differential = DEF_FREQUENCY_DOWN_DIFFERENTIAL,
|
2006-03-10 02:35:27 -07:00
|
|
|
.ignore_nice = 0,
|
[CPUFREQ][2/2] ondemand: updated add powersave_bias tunable
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>
2006-07-31 12:28:12 -06:00
|
|
|
.powersave_bias = 0,
|
2005-04-16 16:20:36 -06:00
|
|
|
};
|
|
|
|
|
ondemand: Solve a big performance issue by counting IOWAIT time as busy
The ondemand cpufreq governor uses CPU busy time (e.g. not-idle
time) as a measure for scaling the CPU frequency up or down.
If the CPU is busy, the CPU frequency scales up, if it's idle,
the CPU frequency scales down. Effectively, it uses the CPU busy
time as proxy variable for the more nebulous "how critical is
performance right now" question.
This algorithm falls flat on its face in the light of workloads
where you're alternatingly disk and CPU bound, such as the ever
popular "git grep", but also things like startup of programs and
maildir using email clients... much to the chagarin of Andrew
Morton.
This patch changes the ondemand algorithm to count iowait time
as busy, not idle, time. As shown in the breakdown cases above,
iowait is performance critical often, and by counting iowait,
the proxy variable becomes a more accurate representation of the
"how critical is performance" question.
The problem and fix are both verified with the "perf timechar"
tool.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dave Jones <davej@redhat.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <20100509082606.3d9f00d0@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-05-09 09:26:06 -06:00
|
|
|
static inline cputime64_t get_cpu_iowait_time(unsigned int cpu, cputime64_t *wall)
|
|
|
|
{
|
|
|
|
u64 iowait_time = get_cpu_iowait_time_us(cpu, wall);
|
|
|
|
|
|
|
|
if (iowait_time == -1ULL)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return iowait_time;
|
|
|
|
}
|
|
|
|
|
[CPUFREQ][2/2] ondemand: updated add powersave_bias tunable
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>
2006-07-31 12:28:12 -06:00
|
|
|
/*
|
|
|
|
* Find right freq to be set now with powersave_bias on.
|
|
|
|
* Returns the freq_hi to be used right now and will set freq_hi_jiffies,
|
|
|
|
* freq_lo, and freq_lo_jiffies in percpu area for averaging freqs.
|
|
|
|
*/
|
2006-08-13 15:00:08 -06:00
|
|
|
static unsigned int powersave_bias_target(struct cpufreq_policy *policy,
|
|
|
|
unsigned int freq_next,
|
|
|
|
unsigned int relation)
|
[CPUFREQ][2/2] ondemand: updated add powersave_bias tunable
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>
2006-07-31 12:28:12 -06:00
|
|
|
{
|
|
|
|
unsigned int freq_req, freq_reduc, freq_avg;
|
|
|
|
unsigned int freq_hi, freq_lo;
|
|
|
|
unsigned int index = 0;
|
|
|
|
unsigned int jiffies_total, jiffies_hi, jiffies_lo;
|
2009-06-24 00:13:48 -06:00
|
|
|
struct cpu_dbs_info_s *dbs_info = &per_cpu(od_cpu_dbs_info,
|
|
|
|
policy->cpu);
|
[CPUFREQ][2/2] ondemand: updated add powersave_bias tunable
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>
2006-07-31 12:28:12 -06:00
|
|
|
|
|
|
|
if (!dbs_info->freq_table) {
|
|
|
|
dbs_info->freq_lo = 0;
|
|
|
|
dbs_info->freq_lo_jiffies = 0;
|
|
|
|
return freq_next;
|
|
|
|
}
|
|
|
|
|
|
|
|
cpufreq_frequency_table_target(policy, dbs_info->freq_table, freq_next,
|
|
|
|
relation, &index);
|
|
|
|
freq_req = dbs_info->freq_table[index].frequency;
|
|
|
|
freq_reduc = freq_req * dbs_tuners_ins.powersave_bias / 1000;
|
|
|
|
freq_avg = freq_req - freq_reduc;
|
|
|
|
|
|
|
|
/* Find freq bounds for freq_avg in freq_table */
|
|
|
|
index = 0;
|
|
|
|
cpufreq_frequency_table_target(policy, dbs_info->freq_table, freq_avg,
|
|
|
|
CPUFREQ_RELATION_H, &index);
|
|
|
|
freq_lo = dbs_info->freq_table[index].frequency;
|
|
|
|
index = 0;
|
|
|
|
cpufreq_frequency_table_target(policy, dbs_info->freq_table, freq_avg,
|
|
|
|
CPUFREQ_RELATION_L, &index);
|
|
|
|
freq_hi = dbs_info->freq_table[index].frequency;
|
|
|
|
|
|
|
|
/* Find out how long we have to be in hi and lo freqs */
|
|
|
|
if (freq_hi == freq_lo) {
|
|
|
|
dbs_info->freq_lo = 0;
|
|
|
|
dbs_info->freq_lo_jiffies = 0;
|
|
|
|
return freq_lo;
|
|
|
|
}
|
|
|
|
jiffies_total = usecs_to_jiffies(dbs_tuners_ins.sampling_rate);
|
|
|
|
jiffies_hi = (freq_avg - freq_lo) * jiffies_total;
|
|
|
|
jiffies_hi += ((freq_hi - freq_lo) / 2);
|
|
|
|
jiffies_hi /= (freq_hi - freq_lo);
|
|
|
|
jiffies_lo = jiffies_total - jiffies_hi;
|
|
|
|
dbs_info->freq_lo = freq_lo;
|
|
|
|
dbs_info->freq_lo_jiffies = jiffies_lo;
|
|
|
|
dbs_info->freq_hi_jiffies = jiffies_hi;
|
|
|
|
return freq_hi;
|
|
|
|
}
|
|
|
|
|
2009-07-02 18:08:32 -06:00
|
|
|
static void ondemand_powersave_bias_init_cpu(int cpu)
|
|
|
|
{
|
2009-08-13 23:41:02 -06:00
|
|
|
struct cpu_dbs_info_s *dbs_info = &per_cpu(od_cpu_dbs_info, cpu);
|
2009-07-02 18:08:32 -06:00
|
|
|
dbs_info->freq_table = cpufreq_frequency_get_table(cpu);
|
|
|
|
dbs_info->freq_lo = 0;
|
|
|
|
}
|
|
|
|
|
[CPUFREQ][2/2] ondemand: updated add powersave_bias tunable
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>
2006-07-31 12:28:12 -06:00
|
|
|
static void ondemand_powersave_bias_init(void)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
for_each_online_cpu(i) {
|
2009-07-02 18:08:32 -06:00
|
|
|
ondemand_powersave_bias_init_cpu(i);
|
[CPUFREQ][2/2] ondemand: updated add powersave_bias tunable
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>
2006-07-31 12:28:12 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
/************************** sysfs interface ************************/
|
2009-07-24 07:25:06 -06:00
|
|
|
|
|
|
|
static ssize_t show_sampling_rate_min(struct kobject *kobj,
|
|
|
|
struct attribute *attr, char *buf)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2009-04-22 05:48:29 -06:00
|
|
|
return sprintf(buf, "%u\n", min_sampling_rate);
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2010-03-31 13:56:46 -06:00
|
|
|
define_one_global_ro(sampling_rate_min);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
/* cpufreq_ondemand Governor Tunables */
|
|
|
|
#define show_one(file_name, object) \
|
|
|
|
static ssize_t show_##file_name \
|
2009-07-24 07:25:06 -06:00
|
|
|
(struct kobject *kobj, struct attribute *attr, char *buf) \
|
2005-04-16 16:20:36 -06:00
|
|
|
{ \
|
|
|
|
return sprintf(buf, "%u\n", dbs_tuners_ins.object); \
|
|
|
|
}
|
|
|
|
show_one(sampling_rate, sampling_rate);
|
2010-05-09 09:26:51 -06:00
|
|
|
show_one(io_is_busy, io_is_busy);
|
2005-04-16 16:20:36 -06:00
|
|
|
show_one(up_threshold, up_threshold);
|
2010-10-06 14:54:24 -06:00
|
|
|
show_one(sampling_down_factor, sampling_down_factor);
|
2005-12-01 02:09:25 -07:00
|
|
|
show_one(ignore_nice_load, ignore_nice);
|
[CPUFREQ][2/2] ondemand: updated add powersave_bias tunable
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>
2006-07-31 12:28:12 -06:00
|
|
|
show_one(powersave_bias, powersave_bias);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2012-02-29 01:54:41 -07:00
|
|
|
/**
|
|
|
|
* update_sampling_rate - update sampling rate effective immediately if needed.
|
|
|
|
* @new_rate: new sampling rate
|
|
|
|
*
|
|
|
|
* If new rate is smaller than the old, simply updaing
|
|
|
|
* dbs_tuners_int.sampling_rate might not be appropriate. For example,
|
|
|
|
* if the original sampling_rate was 1 second and the requested new sampling
|
|
|
|
* rate is 10 ms because the user needs immediate reaction from ondemand
|
|
|
|
* governor, but not sure if higher frequency will be required or not,
|
|
|
|
* then, the governor may change the sampling rate too late; up to 1 second
|
|
|
|
* later. Thus, if we are reducing the sampling rate, we need to make the
|
|
|
|
* new value effective immediately.
|
|
|
|
*/
|
|
|
|
static void update_sampling_rate(unsigned int new_rate)
|
|
|
|
{
|
|
|
|
int cpu;
|
|
|
|
|
|
|
|
dbs_tuners_ins.sampling_rate = new_rate
|
|
|
|
= max(new_rate, min_sampling_rate);
|
|
|
|
|
|
|
|
for_each_online_cpu(cpu) {
|
|
|
|
struct cpufreq_policy *policy;
|
|
|
|
struct cpu_dbs_info_s *dbs_info;
|
|
|
|
unsigned long next_sampling, appointed_at;
|
|
|
|
|
|
|
|
policy = cpufreq_cpu_get(cpu);
|
|
|
|
if (!policy)
|
|
|
|
continue;
|
|
|
|
dbs_info = &per_cpu(od_cpu_dbs_info, policy->cpu);
|
|
|
|
cpufreq_cpu_put(policy);
|
|
|
|
|
|
|
|
mutex_lock(&dbs_info->timer_mutex);
|
|
|
|
|
|
|
|
if (!delayed_work_pending(&dbs_info->work)) {
|
|
|
|
mutex_unlock(&dbs_info->timer_mutex);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
next_sampling = jiffies + usecs_to_jiffies(new_rate);
|
|
|
|
appointed_at = dbs_info->work.timer.expires;
|
|
|
|
|
|
|
|
|
|
|
|
if (time_before(next_sampling, appointed_at)) {
|
|
|
|
|
|
|
|
mutex_unlock(&dbs_info->timer_mutex);
|
|
|
|
cancel_delayed_work_sync(&dbs_info->work);
|
|
|
|
mutex_lock(&dbs_info->timer_mutex);
|
|
|
|
|
|
|
|
schedule_delayed_work_on(dbs_info->cpu, &dbs_info->work,
|
|
|
|
usecs_to_jiffies(new_rate));
|
|
|
|
|
|
|
|
}
|
|
|
|
mutex_unlock(&dbs_info->timer_mutex);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-07-24 07:25:06 -06:00
|
|
|
static ssize_t store_sampling_rate(struct kobject *a, struct attribute *b,
|
|
|
|
const char *buf, size_t count)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
unsigned int input;
|
|
|
|
int ret;
|
2006-06-28 14:52:18 -06:00
|
|
|
ret = sscanf(buf, "%u", &input);
|
2009-07-02 18:08:32 -06:00
|
|
|
if (ret != 1)
|
|
|
|
return -EINVAL;
|
2012-02-29 01:54:41 -07:00
|
|
|
update_sampling_rate(input);
|
2005-04-16 16:20:36 -06:00
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
2010-05-09 09:26:51 -06:00
|
|
|
static ssize_t store_io_is_busy(struct kobject *a, struct attribute *b,
|
|
|
|
const char *buf, size_t count)
|
|
|
|
{
|
|
|
|
unsigned int input;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = sscanf(buf, "%u", &input);
|
|
|
|
if (ret != 1)
|
|
|
|
return -EINVAL;
|
|
|
|
dbs_tuners_ins.io_is_busy = !!input;
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
2009-07-24 07:25:06 -06:00
|
|
|
static ssize_t store_up_threshold(struct kobject *a, struct attribute *b,
|
|
|
|
const char *buf, size_t count)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
unsigned int input;
|
|
|
|
int ret;
|
2006-06-28 14:52:18 -06:00
|
|
|
ret = sscanf(buf, "%u", &input);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2006-02-27 22:43:23 -07:00
|
|
|
if (ret != 1 || input > MAX_FREQUENCY_UP_THRESHOLD ||
|
2005-05-31 20:03:50 -06:00
|
|
|
input < MIN_FREQUENCY_UP_THRESHOLD) {
|
2005-04-16 16:20:36 -06:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
dbs_tuners_ins.up_threshold = input;
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
2010-10-06 14:54:24 -06:00
|
|
|
static ssize_t store_sampling_down_factor(struct kobject *a,
|
|
|
|
struct attribute *b, const char *buf, size_t count)
|
|
|
|
{
|
|
|
|
unsigned int input, j;
|
|
|
|
int ret;
|
|
|
|
ret = sscanf(buf, "%u", &input);
|
|
|
|
|
|
|
|
if (ret != 1 || input > MAX_SAMPLING_DOWN_FACTOR || input < 1)
|
|
|
|
return -EINVAL;
|
|
|
|
dbs_tuners_ins.sampling_down_factor = input;
|
|
|
|
|
|
|
|
/* Reset down sampling multiplier in case it was active */
|
|
|
|
for_each_online_cpu(j) {
|
|
|
|
struct cpu_dbs_info_s *dbs_info;
|
|
|
|
dbs_info = &per_cpu(od_cpu_dbs_info, j);
|
|
|
|
dbs_info->rate_mult = 1;
|
|
|
|
}
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
2009-07-24 07:25:06 -06:00
|
|
|
static ssize_t store_ignore_nice_load(struct kobject *a, struct attribute *b,
|
|
|
|
const char *buf, size_t count)
|
2005-05-31 20:03:47 -06:00
|
|
|
{
|
|
|
|
unsigned int input;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
unsigned int j;
|
2006-02-27 22:43:23 -07:00
|
|
|
|
2006-06-28 14:52:18 -06:00
|
|
|
ret = sscanf(buf, "%u", &input);
|
2009-01-17 23:43:44 -07:00
|
|
|
if (ret != 1)
|
2005-05-31 20:03:47 -06:00
|
|
|
return -EINVAL;
|
|
|
|
|
2009-01-17 23:43:44 -07:00
|
|
|
if (input > 1)
|
2005-05-31 20:03:47 -06:00
|
|
|
input = 1;
|
2006-02-27 22:43:23 -07:00
|
|
|
|
2009-01-17 23:43:44 -07:00
|
|
|
if (input == dbs_tuners_ins.ignore_nice) { /* nothing to do */
|
2005-05-31 20:03:47 -06:00
|
|
|
return count;
|
|
|
|
}
|
|
|
|
dbs_tuners_ins.ignore_nice = input;
|
|
|
|
|
2006-06-28 14:49:52 -06:00
|
|
|
/* we need to re-evaluate prev_cpu_idle */
|
2005-05-31 20:03:49 -06:00
|
|
|
for_each_online_cpu(j) {
|
2006-06-28 14:49:52 -06:00
|
|
|
struct cpu_dbs_info_s *dbs_info;
|
2009-06-24 00:13:48 -06:00
|
|
|
dbs_info = &per_cpu(od_cpu_dbs_info, j);
|
2008-08-04 12:59:09 -06:00
|
|
|
dbs_info->prev_cpu_idle = get_cpu_idle_time(j,
|
|
|
|
&dbs_info->prev_cpu_wall);
|
2009-01-23 07:25:02 -07:00
|
|
|
if (dbs_tuners_ins.ignore_nice)
|
2011-11-28 09:45:17 -07:00
|
|
|
dbs_info->prev_cpu_nice = kcpustat_cpu(j).cpustat[CPUTIME_NICE];
|
2009-01-23 07:25:02 -07:00
|
|
|
|
2005-05-31 20:03:47 -06:00
|
|
|
}
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
2009-07-24 07:25:06 -06:00
|
|
|
static ssize_t store_powersave_bias(struct kobject *a, struct attribute *b,
|
|
|
|
const char *buf, size_t count)
|
[CPUFREQ][2/2] ondemand: updated add powersave_bias tunable
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>
2006-07-31 12:28:12 -06:00
|
|
|
{
|
|
|
|
unsigned int input;
|
|
|
|
int ret;
|
|
|
|
ret = sscanf(buf, "%u", &input);
|
|
|
|
|
|
|
|
if (ret != 1)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (input > 1000)
|
|
|
|
input = 1000;
|
|
|
|
|
|
|
|
dbs_tuners_ins.powersave_bias = input;
|
|
|
|
ondemand_powersave_bias_init();
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
2010-03-31 13:56:46 -06:00
|
|
|
define_one_global_rw(sampling_rate);
|
Merge branch 'x86-cpu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
* 'x86-cpu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
x86, hypervisor: add missing <linux/module.h>
Modify the VMware balloon driver for the new x86_hyper API
x86, hypervisor: Export the x86_hyper* symbols
x86: Clean up the hypervisor layer
x86, HyperV: fix up the license to mshyperv.c
x86: Detect running on a Microsoft HyperV system
x86, cpu: Make APERF/MPERF a normal table-driven flag
x86, k8: Fix build error when K8_NB is disabled
x86, cacheinfo: Disable index in all four subcaches
x86, cacheinfo: Make L3 cache info per node
x86, cacheinfo: Reorganize AMD L3 cache structure
x86, cacheinfo: Turn off L3 cache index disable feature in virtualized environments
x86, cacheinfo: Unify AMD L3 cache index disable checking
cpufreq: Unify sysfs attribute definition macros
powernow-k8: Fix frequency reporting
x86, cpufreq: Add APERF/MPERF support for AMD processors
x86: Unify APERF/MPERF support
powernow-k8: Add core performance boost support
x86, cpu: Add AMD core boosting feature flag to /proc/cpuinfo
Fix up trivial conflicts in arch/x86/kernel/cpu/intel_cacheinfo.c and
drivers/cpufreq/cpufreq_ondemand.c
2010-05-18 09:49:13 -06:00
|
|
|
define_one_global_rw(io_is_busy);
|
2010-03-31 13:56:46 -06:00
|
|
|
define_one_global_rw(up_threshold);
|
2010-10-06 14:54:24 -06:00
|
|
|
define_one_global_rw(sampling_down_factor);
|
2010-03-31 13:56:46 -06:00
|
|
|
define_one_global_rw(ignore_nice_load);
|
|
|
|
define_one_global_rw(powersave_bias);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2009-01-17 23:43:44 -07:00
|
|
|
static struct attribute *dbs_attributes[] = {
|
2005-04-16 16:20:36 -06:00
|
|
|
&sampling_rate_min.attr,
|
|
|
|
&sampling_rate.attr,
|
|
|
|
&up_threshold.attr,
|
2010-10-06 14:54:24 -06:00
|
|
|
&sampling_down_factor.attr,
|
2005-12-01 02:09:25 -07:00
|
|
|
&ignore_nice_load.attr,
|
[CPUFREQ][2/2] ondemand: updated add powersave_bias tunable
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>
2006-07-31 12:28:12 -06:00
|
|
|
&powersave_bias.attr,
|
2010-05-09 09:26:51 -06:00
|
|
|
&io_is_busy.attr,
|
2005-04-16 16:20:36 -06:00
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct attribute_group dbs_attr_group = {
|
|
|
|
.attrs = dbs_attributes,
|
|
|
|
.name = "ondemand",
|
|
|
|
};
|
|
|
|
|
|
|
|
/************************** sysfs end ************************/
|
|
|
|
|
2010-01-26 18:06:47 -07:00
|
|
|
static void dbs_freq_increase(struct cpufreq_policy *p, unsigned int freq)
|
|
|
|
{
|
|
|
|
if (dbs_tuners_ins.powersave_bias)
|
|
|
|
freq = powersave_bias_target(p, freq, CPUFREQ_RELATION_H);
|
|
|
|
else if (p->cur == p->max)
|
|
|
|
return;
|
|
|
|
|
|
|
|
__cpufreq_driver_target(p, freq, dbs_tuners_ins.powersave_bias ?
|
|
|
|
CPUFREQ_RELATION_L : CPUFREQ_RELATION_H);
|
|
|
|
}
|
|
|
|
|
2006-06-28 14:51:19 -06:00
|
|
|
static void dbs_check_cpu(struct cpu_dbs_info_s *this_dbs_info)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2008-08-04 12:59:08 -06:00
|
|
|
unsigned int max_load_freq;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
struct cpufreq_policy *policy;
|
|
|
|
unsigned int j;
|
|
|
|
|
[CPUFREQ][2/2] ondemand: updated add powersave_bias tunable
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>
2006-07-31 12:28:12 -06:00
|
|
|
this_dbs_info->freq_lo = 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
policy = this_dbs_info->cur_policy;
|
2007-06-20 15:26:24 -06:00
|
|
|
|
2006-02-27 22:43:23 -07:00
|
|
|
/*
|
2005-05-31 20:03:50 -06:00
|
|
|
* Every sampling_rate, we check, if current idle time is less
|
|
|
|
* than 20% (default), then we try to increase frequency
|
2006-06-28 14:49:52 -06:00
|
|
|
* Every sampling_rate, we look for a the lowest
|
2005-05-31 20:03:50 -06:00
|
|
|
* frequency which can sustain the load while keeping idle time over
|
|
|
|
* 30%. If such a frequency exist, we try to decrease to this frequency.
|
2005-04-16 16:20:36 -06:00
|
|
|
*
|
2006-02-27 22:43:23 -07:00
|
|
|
* Any frequency increase takes it to the maximum frequency.
|
|
|
|
* Frequency reduction happens at minimum steps of
|
|
|
|
* 5% (default) of current frequency
|
2005-04-16 16:20:36 -06:00
|
|
|
*/
|
|
|
|
|
2008-08-04 12:59:08 -06:00
|
|
|
/* Get Absolute Load - in terms of freq */
|
|
|
|
max_load_freq = 0;
|
|
|
|
|
2009-01-04 06:18:06 -07:00
|
|
|
for_each_cpu(j, policy->cpus) {
|
2005-04-16 16:20:36 -06:00
|
|
|
struct cpu_dbs_info_s *j_dbs_info;
|
ondemand: Solve a big performance issue by counting IOWAIT time as busy
The ondemand cpufreq governor uses CPU busy time (e.g. not-idle
time) as a measure for scaling the CPU frequency up or down.
If the CPU is busy, the CPU frequency scales up, if it's idle,
the CPU frequency scales down. Effectively, it uses the CPU busy
time as proxy variable for the more nebulous "how critical is
performance right now" question.
This algorithm falls flat on its face in the light of workloads
where you're alternatingly disk and CPU bound, such as the ever
popular "git grep", but also things like startup of programs and
maildir using email clients... much to the chagarin of Andrew
Morton.
This patch changes the ondemand algorithm to count iowait time
as busy, not idle, time. As shown in the breakdown cases above,
iowait is performance critical often, and by counting iowait,
the proxy variable becomes a more accurate representation of the
"how critical is performance" question.
The problem and fix are both verified with the "perf timechar"
tool.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dave Jones <davej@redhat.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <20100509082606.3d9f00d0@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-05-09 09:26:06 -06:00
|
|
|
cputime64_t cur_wall_time, cur_idle_time, cur_iowait_time;
|
|
|
|
unsigned int idle_time, wall_time, iowait_time;
|
2008-08-04 12:59:08 -06:00
|
|
|
unsigned int load, load_freq;
|
|
|
|
int freq_avg;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2009-06-24 00:13:48 -06:00
|
|
|
j_dbs_info = &per_cpu(od_cpu_dbs_info, j);
|
2008-08-04 12:59:09 -06:00
|
|
|
|
|
|
|
cur_idle_time = get_cpu_idle_time(j, &cur_wall_time);
|
ondemand: Solve a big performance issue by counting IOWAIT time as busy
The ondemand cpufreq governor uses CPU busy time (e.g. not-idle
time) as a measure for scaling the CPU frequency up or down.
If the CPU is busy, the CPU frequency scales up, if it's idle,
the CPU frequency scales down. Effectively, it uses the CPU busy
time as proxy variable for the more nebulous "how critical is
performance right now" question.
This algorithm falls flat on its face in the light of workloads
where you're alternatingly disk and CPU bound, such as the ever
popular "git grep", but also things like startup of programs and
maildir using email clients... much to the chagarin of Andrew
Morton.
This patch changes the ondemand algorithm to count iowait time
as busy, not idle, time. As shown in the breakdown cases above,
iowait is performance critical often, and by counting iowait,
the proxy variable becomes a more accurate representation of the
"how critical is performance" question.
The problem and fix are both verified with the "perf timechar"
tool.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dave Jones <davej@redhat.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <20100509082606.3d9f00d0@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-05-09 09:26:06 -06:00
|
|
|
cur_iowait_time = get_cpu_iowait_time(j, &cur_wall_time);
|
2008-08-04 12:59:09 -06:00
|
|
|
|
2011-12-15 06:56:09 -07:00
|
|
|
wall_time = (unsigned int)
|
|
|
|
(cur_wall_time - j_dbs_info->prev_cpu_wall);
|
2008-08-04 12:59:08 -06:00
|
|
|
j_dbs_info->prev_cpu_wall = cur_wall_time;
|
|
|
|
|
2011-12-15 06:56:09 -07:00
|
|
|
idle_time = (unsigned int)
|
|
|
|
(cur_idle_time - j_dbs_info->prev_cpu_idle);
|
2008-08-04 12:59:08 -06:00
|
|
|
j_dbs_info->prev_cpu_idle = cur_idle_time;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2011-12-15 06:56:09 -07:00
|
|
|
iowait_time = (unsigned int)
|
|
|
|
(cur_iowait_time - j_dbs_info->prev_cpu_iowait);
|
ondemand: Solve a big performance issue by counting IOWAIT time as busy
The ondemand cpufreq governor uses CPU busy time (e.g. not-idle
time) as a measure for scaling the CPU frequency up or down.
If the CPU is busy, the CPU frequency scales up, if it's idle,
the CPU frequency scales down. Effectively, it uses the CPU busy
time as proxy variable for the more nebulous "how critical is
performance right now" question.
This algorithm falls flat on its face in the light of workloads
where you're alternatingly disk and CPU bound, such as the ever
popular "git grep", but also things like startup of programs and
maildir using email clients... much to the chagarin of Andrew
Morton.
This patch changes the ondemand algorithm to count iowait time
as busy, not idle, time. As shown in the breakdown cases above,
iowait is performance critical often, and by counting iowait,
the proxy variable becomes a more accurate representation of the
"how critical is performance" question.
The problem and fix are both verified with the "perf timechar"
tool.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dave Jones <davej@redhat.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <20100509082606.3d9f00d0@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-05-09 09:26:06 -06:00
|
|
|
j_dbs_info->prev_cpu_iowait = cur_iowait_time;
|
|
|
|
|
2009-01-23 07:25:02 -07:00
|
|
|
if (dbs_tuners_ins.ignore_nice) {
|
2011-11-28 09:45:17 -07:00
|
|
|
u64 cur_nice;
|
2009-01-23 07:25:02 -07:00
|
|
|
unsigned long cur_nice_jiffies;
|
|
|
|
|
2011-11-28 09:45:17 -07:00
|
|
|
cur_nice = kcpustat_cpu(j).cpustat[CPUTIME_NICE] -
|
|
|
|
j_dbs_info->prev_cpu_nice;
|
2009-01-23 07:25:02 -07:00
|
|
|
/*
|
|
|
|
* Assumption: nice time between sampling periods will
|
|
|
|
* be less than 2^32 jiffies for 32 bit sys
|
|
|
|
*/
|
|
|
|
cur_nice_jiffies = (unsigned long)
|
|
|
|
cputime64_to_jiffies64(cur_nice);
|
|
|
|
|
2011-11-28 09:45:17 -07:00
|
|
|
j_dbs_info->prev_cpu_nice = kcpustat_cpu(j).cpustat[CPUTIME_NICE];
|
2009-01-23 07:25:02 -07:00
|
|
|
idle_time += jiffies_to_usecs(cur_nice_jiffies);
|
|
|
|
}
|
|
|
|
|
ondemand: Solve a big performance issue by counting IOWAIT time as busy
The ondemand cpufreq governor uses CPU busy time (e.g. not-idle
time) as a measure for scaling the CPU frequency up or down.
If the CPU is busy, the CPU frequency scales up, if it's idle,
the CPU frequency scales down. Effectively, it uses the CPU busy
time as proxy variable for the more nebulous "how critical is
performance right now" question.
This algorithm falls flat on its face in the light of workloads
where you're alternatingly disk and CPU bound, such as the ever
popular "git grep", but also things like startup of programs and
maildir using email clients... much to the chagarin of Andrew
Morton.
This patch changes the ondemand algorithm to count iowait time
as busy, not idle, time. As shown in the breakdown cases above,
iowait is performance critical often, and by counting iowait,
the proxy variable becomes a more accurate representation of the
"how critical is performance" question.
The problem and fix are both verified with the "perf timechar"
tool.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dave Jones <davej@redhat.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <20100509082606.3d9f00d0@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-05-09 09:26:06 -06:00
|
|
|
/*
|
|
|
|
* For the purpose of ondemand, waiting for disk IO is an
|
|
|
|
* indication that you're performance critical, and not that
|
|
|
|
* the system is actually idle. So subtract the iowait time
|
|
|
|
* from the cpu idle time.
|
|
|
|
*/
|
|
|
|
|
2010-05-09 09:26:51 -06:00
|
|
|
if (dbs_tuners_ins.io_is_busy && idle_time >= iowait_time)
|
ondemand: Solve a big performance issue by counting IOWAIT time as busy
The ondemand cpufreq governor uses CPU busy time (e.g. not-idle
time) as a measure for scaling the CPU frequency up or down.
If the CPU is busy, the CPU frequency scales up, if it's idle,
the CPU frequency scales down. Effectively, it uses the CPU busy
time as proxy variable for the more nebulous "how critical is
performance right now" question.
This algorithm falls flat on its face in the light of workloads
where you're alternatingly disk and CPU bound, such as the ever
popular "git grep", but also things like startup of programs and
maildir using email clients... much to the chagarin of Andrew
Morton.
This patch changes the ondemand algorithm to count iowait time
as busy, not idle, time. As shown in the breakdown cases above,
iowait is performance critical often, and by counting iowait,
the proxy variable becomes a more accurate representation of the
"how critical is performance" question.
The problem and fix are both verified with the "perf timechar"
tool.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dave Jones <davej@redhat.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <20100509082606.3d9f00d0@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-05-09 09:26:06 -06:00
|
|
|
idle_time -= iowait_time;
|
|
|
|
|
2008-08-04 12:59:09 -06:00
|
|
|
if (unlikely(!wall_time || wall_time < idle_time))
|
2008-08-04 12:59:08 -06:00
|
|
|
continue;
|
|
|
|
|
|
|
|
load = 100 * (wall_time - idle_time) / wall_time;
|
|
|
|
|
|
|
|
freq_avg = __cpufreq_driver_getavg(policy, j);
|
|
|
|
if (freq_avg <= 0)
|
|
|
|
freq_avg = policy->cur;
|
|
|
|
|
|
|
|
load_freq = load * freq_avg;
|
|
|
|
if (load_freq > max_load_freq)
|
|
|
|
max_load_freq = load_freq;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2006-06-28 14:49:52 -06:00
|
|
|
/* Check for frequency increase */
|
2008-08-04 12:59:08 -06:00
|
|
|
if (max_load_freq > dbs_tuners_ins.up_threshold * policy->cur) {
|
2010-10-06 14:54:24 -06:00
|
|
|
/* If switching to max speed, apply sampling_down_factor */
|
|
|
|
if (policy->cur < policy->max)
|
|
|
|
this_dbs_info->rate_mult =
|
|
|
|
dbs_tuners_ins.sampling_down_factor;
|
2010-01-26 18:06:47 -07:00
|
|
|
dbs_freq_increase(policy, policy->max);
|
2005-04-16 16:20:36 -06:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check for frequency decrease */
|
2005-05-31 20:03:50 -06:00
|
|
|
/* if we cannot reduce the frequency anymore, break out early */
|
|
|
|
if (policy->cur == policy->min)
|
|
|
|
return;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2005-05-31 20:03:50 -06:00
|
|
|
/*
|
|
|
|
* The optimal frequency is the frequency that is the lowest that
|
|
|
|
* can support the current CPU usage without triggering the up
|
|
|
|
* policy. To be safe, we focus 10 points under the threshold.
|
|
|
|
*/
|
2008-08-04 12:59:10 -06:00
|
|
|
if (max_load_freq <
|
|
|
|
(dbs_tuners_ins.up_threshold - dbs_tuners_ins.down_differential) *
|
|
|
|
policy->cur) {
|
2008-08-04 12:59:08 -06:00
|
|
|
unsigned int freq_next;
|
2008-08-04 12:59:10 -06:00
|
|
|
freq_next = max_load_freq /
|
|
|
|
(dbs_tuners_ins.up_threshold -
|
|
|
|
dbs_tuners_ins.down_differential);
|
2006-10-03 13:38:45 -06:00
|
|
|
|
2010-10-06 14:54:24 -06:00
|
|
|
/* No longer fully busy, reset rate_mult */
|
|
|
|
this_dbs_info->rate_mult = 1;
|
|
|
|
|
2009-12-21 15:40:52 -07:00
|
|
|
if (freq_next < policy->min)
|
|
|
|
freq_next = policy->min;
|
|
|
|
|
[CPUFREQ][2/2] ondemand: updated add powersave_bias tunable
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>
2006-07-31 12:28:12 -06:00
|
|
|
if (!dbs_tuners_ins.powersave_bias) {
|
|
|
|
__cpufreq_driver_target(policy, freq_next,
|
|
|
|
CPUFREQ_RELATION_L);
|
|
|
|
} else {
|
|
|
|
int freq = powersave_bias_target(policy, freq_next,
|
|
|
|
CPUFREQ_RELATION_L);
|
|
|
|
__cpufreq_driver_target(policy, freq,
|
|
|
|
CPUFREQ_RELATION_L);
|
|
|
|
}
|
2006-06-28 14:49:52 -06:00
|
|
|
}
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2006-11-22 07:57:56 -07:00
|
|
|
static void do_dbs_timer(struct work_struct *work)
|
2006-02-27 22:43:23 -07:00
|
|
|
{
|
2007-02-05 17:12:44 -07:00
|
|
|
struct cpu_dbs_info_s *dbs_info =
|
|
|
|
container_of(work, struct cpu_dbs_info_s, work.work);
|
|
|
|
unsigned int cpu = dbs_info->cpu;
|
|
|
|
int sample_type = dbs_info->sample_type;
|
|
|
|
|
2011-02-07 09:14:25 -07:00
|
|
|
int delay;
|
2010-03-11 15:01:11 -07:00
|
|
|
|
2009-07-02 18:08:32 -06:00
|
|
|
mutex_lock(&dbs_info->timer_mutex);
|
2007-02-05 17:12:45 -07:00
|
|
|
|
[CPUFREQ][2/2] ondemand: updated add powersave_bias tunable
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>
2006-07-31 12:28:12 -06:00
|
|
|
/* Common NORMAL_SAMPLE setup */
|
2006-11-22 07:57:56 -07:00
|
|
|
dbs_info->sample_type = DBS_NORMAL_SAMPLE;
|
[CPUFREQ][2/2] ondemand: updated add powersave_bias tunable
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>
2006-07-31 12:28:12 -06:00
|
|
|
if (!dbs_tuners_ins.powersave_bias ||
|
2006-11-22 07:57:56 -07:00
|
|
|
sample_type == DBS_NORMAL_SAMPLE) {
|
[CPUFREQ][2/2] ondemand: updated add powersave_bias tunable
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>
2006-07-31 12:28:12 -06:00
|
|
|
dbs_check_cpu(dbs_info);
|
|
|
|
if (dbs_info->freq_lo) {
|
|
|
|
/* Setup timer for SUB_SAMPLE */
|
2006-11-22 07:57:56 -07:00
|
|
|
dbs_info->sample_type = DBS_SUB_SAMPLE;
|
[CPUFREQ][2/2] ondemand: updated add powersave_bias tunable
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>
2006-07-31 12:28:12 -06:00
|
|
|
delay = dbs_info->freq_hi_jiffies;
|
2011-02-07 09:14:25 -07:00
|
|
|
} else {
|
|
|
|
/* We want all CPUs to do sampling nearly on
|
|
|
|
* same jiffy
|
|
|
|
*/
|
|
|
|
delay = usecs_to_jiffies(dbs_tuners_ins.sampling_rate
|
|
|
|
* dbs_info->rate_mult);
|
|
|
|
|
|
|
|
if (num_online_cpus() > 1)
|
|
|
|
delay -= jiffies % delay;
|
[CPUFREQ][2/2] ondemand: updated add powersave_bias tunable
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>
2006-07-31 12:28:12 -06:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
__cpufreq_driver_target(dbs_info->cur_policy,
|
2009-01-17 23:43:44 -07:00
|
|
|
dbs_info->freq_lo, CPUFREQ_RELATION_H);
|
2011-02-07 09:14:25 -07:00
|
|
|
delay = dbs_info->freq_lo_jiffies;
|
[CPUFREQ][2/2] ondemand: updated add powersave_bias tunable
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>
2006-07-31 12:28:12 -06:00
|
|
|
}
|
2011-01-26 04:12:50 -07:00
|
|
|
schedule_delayed_work_on(cpu, &dbs_info->work, delay);
|
2009-07-02 18:08:32 -06:00
|
|
|
mutex_unlock(&dbs_info->timer_mutex);
|
2006-02-27 22:43:23 -07:00
|
|
|
}
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2007-02-05 17:12:44 -07:00
|
|
|
static inline void dbs_timer_init(struct cpu_dbs_info_s *dbs_info)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2006-07-31 12:25:20 -06:00
|
|
|
/* We want all CPUs to do sampling nearly on same jiffy */
|
|
|
|
int delay = usecs_to_jiffies(dbs_tuners_ins.sampling_rate);
|
2010-03-11 15:01:11 -07:00
|
|
|
|
|
|
|
if (num_online_cpus() > 1)
|
|
|
|
delay -= jiffies % delay;
|
2006-06-28 14:51:19 -06:00
|
|
|
|
2006-11-22 07:57:56 -07:00
|
|
|
dbs_info->sample_type = DBS_NORMAL_SAMPLE;
|
2012-08-21 14:18:23 -06:00
|
|
|
INIT_DEFERRABLE_WORK(&dbs_info->work, do_dbs_timer);
|
2011-01-26 04:12:50 -07:00
|
|
|
schedule_delayed_work_on(dbs_info->cpu, &dbs_info->work, delay);
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2006-07-23 13:05:00 -06:00
|
|
|
static inline void dbs_timer_exit(struct cpu_dbs_info_s *dbs_info)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2009-05-17 08:30:45 -06:00
|
|
|
cancel_delayed_work_sync(&dbs_info->work);
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2010-05-09 09:26:51 -06:00
|
|
|
/*
|
|
|
|
* Not all CPUs want IO time to be accounted as busy; this dependson how
|
|
|
|
* efficient idling at a higher frequency/voltage is.
|
|
|
|
* Pavel Machek says this is not so for various generations of AMD and old
|
|
|
|
* Intel systems.
|
|
|
|
* Mike Chan (androidlcom) calis this is also not true for ARM.
|
|
|
|
* Because of this, whitelist specific known (series) of CPUs by default, and
|
|
|
|
* leave all others up to the user.
|
|
|
|
*/
|
|
|
|
static int should_io_be_busy(void)
|
|
|
|
{
|
|
|
|
#if defined(CONFIG_X86)
|
|
|
|
/*
|
|
|
|
* For Intel, Core 2 (model 15) andl later have an efficient idle.
|
|
|
|
*/
|
|
|
|
if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
|
|
|
|
boot_cpu_data.x86 == 6 &&
|
|
|
|
boot_cpu_data.x86_model >= 15)
|
|
|
|
return 1;
|
|
|
|
#endif
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
|
|
|
|
unsigned int event)
|
|
|
|
{
|
|
|
|
unsigned int cpu = policy->cpu;
|
|
|
|
struct cpu_dbs_info_s *this_dbs_info;
|
|
|
|
unsigned int j;
|
2006-10-20 15:31:00 -06:00
|
|
|
int rc;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2009-06-24 00:13:48 -06:00
|
|
|
this_dbs_info = &per_cpu(od_cpu_dbs_info, cpu);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
switch (event) {
|
|
|
|
case CPUFREQ_GOV_START:
|
2006-06-28 14:52:18 -06:00
|
|
|
if ((!cpu_online(cpu)) || (!policy->cur))
|
2005-04-16 16:20:36 -06:00
|
|
|
return -EINVAL;
|
|
|
|
|
2006-01-13 16:54:22 -07:00
|
|
|
mutex_lock(&dbs_mutex);
|
2006-10-20 15:31:00 -06:00
|
|
|
|
2009-07-02 18:08:32 -06:00
|
|
|
dbs_enable++;
|
2009-01-04 06:18:06 -07:00
|
|
|
for_each_cpu(j, policy->cpus) {
|
2005-04-16 16:20:36 -06:00
|
|
|
struct cpu_dbs_info_s *j_dbs_info;
|
2009-06-24 00:13:48 -06:00
|
|
|
j_dbs_info = &per_cpu(od_cpu_dbs_info, j);
|
2005-04-16 16:20:36 -06:00
|
|
|
j_dbs_info->cur_policy = policy;
|
2006-02-27 22:43:23 -07:00
|
|
|
|
2008-08-04 12:59:09 -06:00
|
|
|
j_dbs_info->prev_cpu_idle = get_cpu_idle_time(j,
|
|
|
|
&j_dbs_info->prev_cpu_wall);
|
2011-11-28 09:45:17 -07:00
|
|
|
if (dbs_tuners_ins.ignore_nice)
|
2009-01-23 07:25:02 -07:00
|
|
|
j_dbs_info->prev_cpu_nice =
|
2011-11-28 09:45:17 -07:00
|
|
|
kcpustat_cpu(j).cpustat[CPUTIME_NICE];
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
2007-02-05 17:12:44 -07:00
|
|
|
this_dbs_info->cpu = cpu;
|
2010-10-06 14:54:24 -06:00
|
|
|
this_dbs_info->rate_mult = 1;
|
2009-07-02 18:08:32 -06:00
|
|
|
ondemand_powersave_bias_init_cpu(cpu);
|
2005-04-16 16:20:36 -06:00
|
|
|
/*
|
|
|
|
* Start the timerschedule work, when this governor
|
|
|
|
* is used for first time
|
|
|
|
*/
|
|
|
|
if (dbs_enable == 1) {
|
|
|
|
unsigned int latency;
|
2009-07-24 07:25:06 -06:00
|
|
|
|
|
|
|
rc = sysfs_create_group(cpufreq_global_kobject,
|
|
|
|
&dbs_attr_group);
|
|
|
|
if (rc) {
|
|
|
|
mutex_unlock(&dbs_mutex);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
/* policy latency is in nS. Convert it to uS first */
|
[CPUFREQ] Avoid the ondemand cpufreq governor to use a too high frequency for stats.
The problem is in the ondemand governor, there is a periodic measurement
of the CPU usage. This CPU usage is updated by the scheduler after every
tick (basically, by adding 1 either to "idle" or to "user" or to
"system"). So if the frequency of the governor is too high, the stat
will be meaningless (as mostly no number have changed).
So this patch checks that the measurements are separated by at least 10
ticks. It means that by default, stats will have about 5% error (20
ticks). Of course those numbers can be argued but, IMHO, they look sane.
The patch also includes a small clean-up to check more explictly the
result of the conversion from ns to µs being null.
Let's note that (on x86) this has never been really needed before 2.6.13
because HZ was always 1000. Now that HZ can be 100, some CPU might be
affected by this problem. For instance when HZ=100, the centrino ,which
has a 10µs transition latency, would lead to the governor allowing to
read stats every tick (10ms)!
Signed-off-by: Eric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Dave Jones <davej@redhat.com>
2005-09-20 13:39:35 -06:00
|
|
|
latency = policy->cpuinfo.transition_latency / 1000;
|
|
|
|
if (latency == 0)
|
|
|
|
latency = 1;
|
2009-04-22 05:48:29 -06:00
|
|
|
/* Bring kernel and HW constraints together */
|
|
|
|
min_sampling_rate = max(min_sampling_rate,
|
|
|
|
MIN_LATENCY_MULTIPLIER * latency);
|
|
|
|
dbs_tuners_ins.sampling_rate =
|
|
|
|
max(min_sampling_rate,
|
|
|
|
latency * LATENCY_MULTIPLIER);
|
2010-05-09 09:26:51 -06:00
|
|
|
dbs_tuners_ins.io_is_busy = should_io_be_busy();
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
2006-01-13 16:54:22 -07:00
|
|
|
mutex_unlock(&dbs_mutex);
|
2009-07-02 18:08:30 -06:00
|
|
|
|
2009-07-24 07:25:06 -06:00
|
|
|
mutex_init(&this_dbs_info->timer_mutex);
|
2009-07-02 18:08:30 -06:00
|
|
|
dbs_timer_init(this_dbs_info);
|
2005-04-16 16:20:36 -06:00
|
|
|
break;
|
|
|
|
|
|
|
|
case CPUFREQ_GOV_STOP:
|
2006-07-23 13:05:00 -06:00
|
|
|
dbs_timer_exit(this_dbs_info);
|
2009-07-02 18:08:30 -06:00
|
|
|
|
|
|
|
mutex_lock(&dbs_mutex);
|
2009-07-02 18:08:32 -06:00
|
|
|
mutex_destroy(&this_dbs_info->timer_mutex);
|
2005-04-16 16:20:36 -06:00
|
|
|
dbs_enable--;
|
2006-01-13 16:54:22 -07:00
|
|
|
mutex_unlock(&dbs_mutex);
|
2009-07-24 07:25:06 -06:00
|
|
|
if (!dbs_enable)
|
|
|
|
sysfs_remove_group(cpufreq_global_kobject,
|
|
|
|
&dbs_attr_group);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
case CPUFREQ_GOV_LIMITS:
|
2009-07-02 18:08:32 -06:00
|
|
|
mutex_lock(&this_dbs_info->timer_mutex);
|
2005-04-16 16:20:36 -06:00
|
|
|
if (policy->max < this_dbs_info->cur_policy->cur)
|
2006-06-28 14:52:18 -06:00
|
|
|
__cpufreq_driver_target(this_dbs_info->cur_policy,
|
2009-01-17 23:43:44 -07:00
|
|
|
policy->max, CPUFREQ_RELATION_H);
|
2005-04-16 16:20:36 -06:00
|
|
|
else if (policy->min > this_dbs_info->cur_policy->cur)
|
2006-06-28 14:52:18 -06:00
|
|
|
__cpufreq_driver_target(this_dbs_info->cur_policy,
|
2009-01-17 23:43:44 -07:00
|
|
|
policy->min, CPUFREQ_RELATION_L);
|
2012-09-14 13:07:39 -06:00
|
|
|
dbs_check_cpu(this_dbs_info);
|
2009-07-02 18:08:32 -06:00
|
|
|
mutex_unlock(&this_dbs_info->timer_mutex);
|
2005-04-16 16:20:36 -06:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int __init cpufreq_gov_dbs_init(void)
|
|
|
|
{
|
2008-09-18 04:43:40 -06:00
|
|
|
u64 idle_time;
|
|
|
|
int cpu = get_cpu();
|
2008-08-04 12:59:12 -06:00
|
|
|
|
2011-12-09 03:48:42 -07:00
|
|
|
idle_time = get_cpu_idle_time_us(cpu, NULL);
|
2008-09-18 04:43:40 -06:00
|
|
|
put_cpu();
|
2008-08-04 12:59:12 -06:00
|
|
|
if (idle_time != -1ULL) {
|
|
|
|
/* Idle micro accounting is supported. Use finer thresholds */
|
|
|
|
dbs_tuners_ins.up_threshold = MICRO_FREQUENCY_UP_THRESHOLD;
|
|
|
|
dbs_tuners_ins.down_differential =
|
|
|
|
MICRO_FREQUENCY_DOWN_DIFFERENTIAL;
|
2009-04-22 05:48:29 -06:00
|
|
|
/*
|
2011-08-06 06:33:43 -06:00
|
|
|
* In nohz/micro accounting case we set the minimum frequency
|
2009-04-22 05:48:29 -06:00
|
|
|
* not depending on HZ, but fixed (very low). The deferred
|
|
|
|
* timer might skip some samples if idle/sleeping as needed.
|
|
|
|
*/
|
|
|
|
min_sampling_rate = MICRO_FREQUENCY_MIN_SAMPLE_RATE;
|
|
|
|
} else {
|
|
|
|
/* For correct statistics, we need 10 ticks for each measure */
|
|
|
|
min_sampling_rate =
|
|
|
|
MIN_SAMPLING_RATE_RATIO * jiffies_to_usecs(10);
|
2008-08-04 12:59:12 -06:00
|
|
|
}
|
2008-07-13 21:00:45 -06:00
|
|
|
|
2011-01-26 04:12:50 -07:00
|
|
|
return cpufreq_register_governor(&cpufreq_gov_ondemand);
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
static void __exit cpufreq_gov_dbs_exit(void)
|
|
|
|
{
|
2007-10-02 14:28:12 -06:00
|
|
|
cpufreq_unregister_governor(&cpufreq_gov_ondemand);
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2006-06-28 14:52:18 -06:00
|
|
|
MODULE_AUTHOR("Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>");
|
|
|
|
MODULE_AUTHOR("Alexey Starikovskiy <alexey.y.starikovskiy@intel.com>");
|
|
|
|
MODULE_DESCRIPTION("'cpufreq_ondemand' - A dynamic cpufreq governor for "
|
2009-01-17 23:43:44 -07:00
|
|
|
"Low Latency Frequency Transition capable processors");
|
2006-06-28 14:52:18 -06:00
|
|
|
MODULE_LICENSE("GPL");
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2008-01-17 16:21:08 -07:00
|
|
|
#ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
|
|
|
|
fs_initcall(cpufreq_gov_dbs_init);
|
|
|
|
#else
|
2005-04-16 16:20:36 -06:00
|
|
|
module_init(cpufreq_gov_dbs_init);
|
2008-01-17 16:21:08 -07:00
|
|
|
#endif
|
2005-04-16 16:20:36 -06:00
|
|
|
module_exit(cpufreq_gov_dbs_exit);
|