2005-04-17 02:20:36 +04: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 .
*/
2012-10-26 02:47:42 +04:00
# define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
2005-04-17 02:20:36 +04:00
# include <linux/cpufreq.h>
2012-10-26 02:47:42 +04:00
# include <linux/init.h>
# include <linux/kernel.h>
2005-04-17 02:20:36 +04:00
# include <linux/kernel_stat.h>
2012-10-26 02:47:42 +04:00
# include <linux/kobject.h>
# include <linux/module.h>
2006-01-14 02:54:22 +03:00
# include <linux/mutex.h>
2012-10-26 02:47:42 +04:00
# include <linux/percpu-defs.h>
2013-03-27 19:58:58 +04:00
# include <linux/slab.h>
2012-10-26 02:47:42 +04:00
# include <linux/sysfs.h>
2008-08-04 22:59:12 +04:00
# include <linux/tick.h>
2012-10-26 02:47:42 +04:00
# include <linux/types.h>
2005-04-17 02:20:36 +04:00
2012-10-26 02:47:42 +04:00
# include "cpufreq_governor.h"
2005-04-17 02:20:36 +04:00
2013-02-08 21:24:18 +04:00
/* On-demand governor macros */
2008-08-04 22:59:10 +04:00
# define DEF_FREQUENCY_DOWN_DIFFERENTIAL (10)
2005-04-17 02:20:36 +04:00
# define DEF_FREQUENCY_UP_THRESHOLD (80)
2010-10-07 00:54:24 +04:00
# define DEF_SAMPLING_DOWN_FACTOR (1)
# define MAX_SAMPLING_DOWN_FACTOR (100000)
2008-08-04 22:59:12 +04:00
# define MICRO_FREQUENCY_DOWN_DIFFERENTIAL (3)
# define MICRO_FREQUENCY_UP_THRESHOLD (95)
2009-04-22 15:48:29 +04:00
# define MICRO_FREQUENCY_MIN_SAMPLE_RATE (10000)
2005-06-01 06:03:50 +04:00
# define MIN_FREQUENCY_UP_THRESHOLD (11)
2005-04-17 02:20:36 +04:00
# define MAX_FREQUENCY_UP_THRESHOLD (100)
2012-10-26 02:47:42 +04:00
static DEFINE_PER_CPU ( struct od_cpu_dbs_info_s , od_cpu_dbs_info ) ;
2005-04-17 02:20:36 +04:00
2012-11-26 22:10:12 +04:00
# ifndef CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
static struct cpufreq_governor cpufreq_gov_ondemand ;
# endif
2012-10-26 02:47:42 +04:00
static void ondemand_powersave_bias_init_cpu ( int cpu )
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 19:26:06 +04:00
{
2012-10-26 02:47:42 +04:00
struct od_cpu_dbs_info_s * dbs_info = & per_cpu ( od_cpu_dbs_info , cpu ) ;
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 19:26:06 +04:00
2012-10-26 02:47:42 +04:00
dbs_info - > freq_table = cpufreq_frequency_get_table ( cpu ) ;
dbs_info - > freq_lo = 0 ;
}
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 19:26:06 +04:00
2012-10-26 02:47:42 +04:00
/*
* Not all CPUs want IO time to be accounted as busy ; this depends on 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 .
2013-02-08 21:24:18 +04:00
* Mike Chan ( android . com ) claims this is also not true for ARM .
2012-10-26 02:47:42 +04:00
* 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)
/*
2013-02-08 21:24:18 +04:00
* For Intel , Core 2 ( model 15 ) and later have an efficient idle .
2012-10-26 02:47:42 +04:00
*/
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 ;
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 19:26:06 +04: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 22:28:12 +04: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-14 01:00:08 +04:00
static unsigned int powersave_bias_target ( struct cpufreq_policy * policy ,
2012-10-26 02:47:42 +04:00
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 22:28:12 +04: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 ;
2012-10-26 02:47:42 +04:00
struct od_cpu_dbs_info_s * dbs_info = & per_cpu ( od_cpu_dbs_info ,
2009-06-24 10:13:48 +04:00
policy - > cpu ) ;
2013-03-27 19:58:58 +04:00
struct dbs_data * dbs_data = policy - > governor_data ;
struct od_dbs_tuners * od_tuners = dbs_data - > tuners ;
[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 22:28:12 +04: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 ;
2013-03-27 19:58:58 +04:00
freq_reduc = freq_req * od_tuners - > powersave_bias / 1000 ;
[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 22:28:12 +04:00
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 ;
}
2013-03-27 19:58:58 +04:00
jiffies_total = usecs_to_jiffies ( od_tuners - > sampling_rate ) ;
[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 22:28:12 +04:00
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 ;
}
static void ondemand_powersave_bias_init ( void )
{
int i ;
for_each_online_cpu ( i ) {
2009-07-03 04:08:32 +04: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 22:28:12 +04:00
}
}
2012-10-26 02:47:42 +04:00
static void dbs_freq_increase ( struct cpufreq_policy * p , unsigned int freq )
{
2013-03-27 19:58:58 +04:00
struct dbs_data * dbs_data = p - > governor_data ;
struct od_dbs_tuners * od_tuners = dbs_data - > tuners ;
if ( od_tuners - > powersave_bias )
2012-10-26 02:47:42 +04:00
freq = powersave_bias_target ( p , freq , CPUFREQ_RELATION_H ) ;
else if ( p - > cur = = p - > max )
return ;
2009-07-24 17:25:06 +04:00
2013-03-27 19:58:58 +04:00
__cpufreq_driver_target ( p , freq , od_tuners - > powersave_bias ?
2012-10-26 02:47:42 +04:00
CPUFREQ_RELATION_L : CPUFREQ_RELATION_H ) ;
}
/*
* Every sampling_rate , we check , if current idle time is less than 20 %
2013-02-08 21:24:18 +04:00
* ( default ) , then we try to increase frequency . Every sampling_rate , we look
* for the lowest frequency which can sustain the load while keeping idle time
2012-10-26 02:47:42 +04:00
* over 30 % . If such a frequency exist , we try to decrease to this frequency .
*
* Any frequency increase takes it to the maximum frequency . Frequency reduction
* happens at minimum steps of 5 % ( default ) of current frequency
*/
static void od_check_cpu ( int cpu , unsigned int load_freq )
2005-04-17 02:20:36 +04:00
{
2012-10-26 02:47:42 +04:00
struct od_cpu_dbs_info_s * dbs_info = & per_cpu ( od_cpu_dbs_info , cpu ) ;
struct cpufreq_policy * policy = dbs_info - > cdbs . cur_policy ;
2013-03-27 19:58:58 +04:00
struct dbs_data * dbs_data = policy - > governor_data ;
struct od_dbs_tuners * od_tuners = dbs_data - > tuners ;
2012-10-26 02:47:42 +04:00
dbs_info - > freq_lo = 0 ;
/* Check for frequency increase */
2013-03-27 19:58:58 +04:00
if ( load_freq > od_tuners - > up_threshold * policy - > cur ) {
2012-10-26 02:47:42 +04:00
/* If switching to max speed, apply sampling_down_factor */
if ( policy - > cur < policy - > max )
dbs_info - > rate_mult =
2013-03-27 19:58:58 +04:00
od_tuners - > sampling_down_factor ;
2012-10-26 02:47:42 +04:00
dbs_freq_increase ( policy , policy - > max ) ;
return ;
}
/* Check for frequency decrease */
/* if we cannot reduce the frequency anymore, break out early */
if ( policy - > cur = = policy - > min )
return ;
/*
* 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 .
*/
2013-03-27 19:58:58 +04:00
if ( load_freq < od_tuners - > adj_up_threshold
* policy - > cur ) {
2012-10-26 02:47:42 +04:00
unsigned int freq_next ;
2013-03-27 19:58:58 +04:00
freq_next = load_freq / od_tuners - > adj_up_threshold ;
2012-10-26 02:47:42 +04:00
/* No longer fully busy, reset rate_mult */
dbs_info - > rate_mult = 1 ;
if ( freq_next < policy - > min )
freq_next = policy - > min ;
2013-03-27 19:58:58 +04:00
if ( ! od_tuners - > powersave_bias ) {
2012-10-26 02:47:42 +04:00
__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 ) ;
}
}
2005-04-17 02:20:36 +04:00
}
2013-01-31 21:28:02 +04:00
static void od_dbs_timer ( struct work_struct * work )
2012-10-26 02:47:42 +04:00
{
2013-01-31 21:28:02 +04:00
struct od_cpu_dbs_info_s * dbs_info =
container_of ( work , struct od_cpu_dbs_info_s , cdbs . work . work ) ;
2013-01-31 14:39:19 +04:00
unsigned int cpu = dbs_info - > cdbs . cur_policy - > cpu ;
2013-01-31 21:28:02 +04:00
struct od_cpu_dbs_info_s * core_dbs_info = & per_cpu ( od_cpu_dbs_info ,
cpu ) ;
2013-03-27 19:58:58 +04:00
struct dbs_data * dbs_data = dbs_info - > cdbs . cur_policy - > governor_data ;
struct od_dbs_tuners * od_tuners = dbs_data - > tuners ;
2013-02-27 09:36:36 +04:00
int delay = 0 , sample_type = core_dbs_info - > sample_type ;
2013-02-27 10:54:03 +04:00
bool modify_all = true ;
2013-01-31 21:28:02 +04:00
mutex_lock ( & core_dbs_info - > cdbs . timer_mutex ) ;
2013-02-27 10:54:03 +04:00
if ( ! need_load_eval ( & core_dbs_info - > cdbs , od_tuners - > sampling_rate ) ) {
modify_all = false ;
2013-02-27 09:36:36 +04:00
goto max_delay ;
2013-02-27 10:54:03 +04:00
}
2005-04-17 02:20:36 +04:00
2012-10-26 02:47:42 +04:00
/* Common NORMAL_SAMPLE setup */
2013-01-31 21:28:02 +04:00
core_dbs_info - > sample_type = OD_NORMAL_SAMPLE ;
2012-10-26 02:47:42 +04:00
if ( sample_type = = OD_SUB_SAMPLE ) {
2013-01-31 21:28:02 +04:00
delay = core_dbs_info - > freq_lo_jiffies ;
2013-02-27 09:36:36 +04:00
__cpufreq_driver_target ( core_dbs_info - > cdbs . cur_policy ,
core_dbs_info - > freq_lo , CPUFREQ_RELATION_H ) ;
2012-10-26 02:47:42 +04:00
} else {
2013-02-27 09:36:36 +04:00
dbs_check_cpu ( dbs_data , cpu ) ;
2013-01-31 21:28:02 +04:00
if ( core_dbs_info - > freq_lo ) {
2012-10-26 02:47:42 +04:00
/* Setup timer for SUB_SAMPLE */
2013-01-31 21:28:02 +04:00
core_dbs_info - > sample_type = OD_SUB_SAMPLE ;
delay = core_dbs_info - > freq_hi_jiffies ;
2012-10-26 02:47:42 +04:00
}
}
2013-02-27 09:36:36 +04:00
max_delay :
if ( ! delay )
delay = delay_for_sampling_rate ( od_tuners - > sampling_rate
* core_dbs_info - > rate_mult ) ;
2013-02-27 10:54:03 +04:00
gov_queue_work ( dbs_data , dbs_info - > cdbs . cur_policy , delay , modify_all ) ;
2013-01-31 21:28:02 +04:00
mutex_unlock ( & core_dbs_info - > cdbs . timer_mutex ) ;
2012-12-27 18:55:40 +04:00
}
2012-10-26 02:47:42 +04:00
/************************** sysfs interface ************************/
2013-03-27 19:58:58 +04:00
static struct common_dbs_data od_dbs_cdata ;
2005-04-17 02:20:36 +04:00
2012-02-29 12:54:41 +04:00
/**
* update_sampling_rate - update sampling rate effective immediately if needed .
* @ new_rate : new sampling rate
*
2013-02-08 21:24:18 +04:00
* If new rate is smaller than the old , simply updating
2012-10-26 02:47:42 +04:00
* 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 .
2012-02-29 12:54:41 +04:00
*/
2013-03-27 19:58:58 +04:00
static void update_sampling_rate ( struct dbs_data * dbs_data ,
unsigned int new_rate )
2012-02-29 12:54:41 +04:00
{
2013-03-27 19:58:58 +04:00
struct od_dbs_tuners * od_tuners = dbs_data - > tuners ;
2012-02-29 12:54:41 +04:00
int cpu ;
2013-03-27 19:58:58 +04:00
od_tuners - > sampling_rate = new_rate = max ( new_rate ,
dbs_data - > min_sampling_rate ) ;
2012-02-29 12:54:41 +04:00
for_each_online_cpu ( cpu ) {
struct cpufreq_policy * policy ;
2012-10-26 02:47:42 +04:00
struct od_cpu_dbs_info_s * dbs_info ;
2012-02-29 12:54:41 +04:00
unsigned long next_sampling , appointed_at ;
policy = cpufreq_cpu_get ( cpu ) ;
if ( ! policy )
continue ;
2012-11-26 22:10:12 +04:00
if ( policy - > governor ! = & cpufreq_gov_ondemand ) {
cpufreq_cpu_put ( policy ) ;
continue ;
}
2012-12-27 18:55:42 +04:00
dbs_info = & per_cpu ( od_cpu_dbs_info , cpu ) ;
2012-02-29 12:54:41 +04:00
cpufreq_cpu_put ( policy ) ;
2012-10-26 02:47:42 +04:00
mutex_lock ( & dbs_info - > cdbs . timer_mutex ) ;
2012-02-29 12:54:41 +04:00
2012-10-26 02:47:42 +04:00
if ( ! delayed_work_pending ( & dbs_info - > cdbs . work ) ) {
mutex_unlock ( & dbs_info - > cdbs . timer_mutex ) ;
2012-02-29 12:54:41 +04:00
continue ;
}
2012-10-26 02:47:42 +04:00
next_sampling = jiffies + usecs_to_jiffies ( new_rate ) ;
appointed_at = dbs_info - > cdbs . work . timer . expires ;
2012-02-29 12:54:41 +04:00
if ( time_before ( next_sampling , appointed_at ) ) {
2012-10-26 02:47:42 +04:00
mutex_unlock ( & dbs_info - > cdbs . timer_mutex ) ;
cancel_delayed_work_sync ( & dbs_info - > cdbs . work ) ;
mutex_lock ( & dbs_info - > cdbs . timer_mutex ) ;
2012-02-29 12:54:41 +04:00
2013-02-27 10:54:03 +04:00
gov_queue_work ( dbs_data , dbs_info - > cdbs . cur_policy ,
usecs_to_jiffies ( new_rate ) , true ) ;
2012-02-29 12:54:41 +04:00
}
2012-10-26 02:47:42 +04:00
mutex_unlock ( & dbs_info - > cdbs . timer_mutex ) ;
2012-02-29 12:54:41 +04:00
}
}
2013-03-27 19:58:58 +04:00
static ssize_t store_sampling_rate ( struct dbs_data * dbs_data , const char * buf ,
size_t count )
2005-04-17 02:20:36 +04:00
{
unsigned int input ;
int ret ;
2006-06-29 00:52:18 +04:00
ret = sscanf ( buf , " %u " , & input ) ;
2009-07-03 04:08:32 +04:00
if ( ret ! = 1 )
return - EINVAL ;
2013-03-27 19:58:58 +04:00
update_sampling_rate ( dbs_data , input ) ;
2005-04-17 02:20:36 +04:00
return count ;
}
2013-03-27 19:58:58 +04:00
static ssize_t store_io_is_busy ( struct dbs_data * dbs_data , const char * buf ,
size_t count )
2010-05-09 19:26:51 +04:00
{
2013-03-27 19:58:58 +04:00
struct od_dbs_tuners * od_tuners = dbs_data - > tuners ;
2010-05-09 19:26:51 +04:00
unsigned int input ;
int ret ;
ret = sscanf ( buf , " %u " , & input ) ;
if ( ret ! = 1 )
return - EINVAL ;
2013-03-27 19:58:58 +04:00
od_tuners - > io_is_busy = ! ! input ;
2010-05-09 19:26:51 +04:00
return count ;
}
2013-03-27 19:58:58 +04:00
static ssize_t store_up_threshold ( struct dbs_data * dbs_data , const char * buf ,
size_t count )
2005-04-17 02:20:36 +04:00
{
2013-03-27 19:58:58 +04:00
struct od_dbs_tuners * od_tuners = dbs_data - > tuners ;
2005-04-17 02:20:36 +04:00
unsigned int input ;
int ret ;
2006-06-29 00:52:18 +04:00
ret = sscanf ( buf , " %u " , & input ) ;
2005-04-17 02:20:36 +04:00
2006-02-28 08:43:23 +03:00
if ( ret ! = 1 | | input > MAX_FREQUENCY_UP_THRESHOLD | |
2005-06-01 06:03:50 +04:00
input < MIN_FREQUENCY_UP_THRESHOLD ) {
2005-04-17 02:20:36 +04:00
return - EINVAL ;
}
2013-02-06 16:34:00 +04:00
/* Calculate the new adj_up_threshold */
2013-03-27 19:58:58 +04:00
od_tuners - > adj_up_threshold + = input ;
od_tuners - > adj_up_threshold - = od_tuners - > up_threshold ;
2013-02-06 16:34:00 +04:00
2013-03-27 19:58:58 +04:00
od_tuners - > up_threshold = input ;
2005-04-17 02:20:36 +04:00
return count ;
}
2013-03-27 19:58:58 +04:00
static ssize_t store_sampling_down_factor ( struct dbs_data * dbs_data ,
const char * buf , size_t count )
2010-10-07 00:54:24 +04:00
{
2013-03-27 19:58:58 +04:00
struct od_dbs_tuners * od_tuners = dbs_data - > tuners ;
2010-10-07 00:54:24 +04:00
unsigned int input , j ;
int ret ;
ret = sscanf ( buf , " %u " , & input ) ;
if ( ret ! = 1 | | input > MAX_SAMPLING_DOWN_FACTOR | | input < 1 )
return - EINVAL ;
2013-03-27 19:58:58 +04:00
od_tuners - > sampling_down_factor = input ;
2010-10-07 00:54:24 +04:00
/* Reset down sampling multiplier in case it was active */
for_each_online_cpu ( j ) {
2012-10-26 02:47:42 +04:00
struct od_cpu_dbs_info_s * dbs_info = & per_cpu ( od_cpu_dbs_info ,
j ) ;
2010-10-07 00:54:24 +04:00
dbs_info - > rate_mult = 1 ;
}
return count ;
}
2013-03-27 19:58:58 +04:00
static ssize_t store_ignore_nice ( struct dbs_data * dbs_data , const char * buf ,
size_t count )
2005-06-01 06:03:47 +04:00
{
2013-03-27 19:58:58 +04:00
struct od_dbs_tuners * od_tuners = dbs_data - > tuners ;
2005-06-01 06:03:47 +04:00
unsigned int input ;
int ret ;
unsigned int j ;
2006-02-28 08:43:23 +03:00
2006-06-29 00:52:18 +04:00
ret = sscanf ( buf , " %u " , & input ) ;
2009-01-18 09:43:44 +03:00
if ( ret ! = 1 )
2005-06-01 06:03:47 +04:00
return - EINVAL ;
2009-01-18 09:43:44 +03:00
if ( input > 1 )
2005-06-01 06:03:47 +04:00
input = 1 ;
2006-02-28 08:43:23 +03:00
2013-03-27 19:58:58 +04:00
if ( input = = od_tuners - > ignore_nice ) { /* nothing to do */
2005-06-01 06:03:47 +04:00
return count ;
}
2013-03-27 19:58:58 +04:00
od_tuners - > ignore_nice = input ;
2005-06-01 06:03:47 +04:00
2006-06-29 00:49:52 +04:00
/* we need to re-evaluate prev_cpu_idle */
2005-06-01 06:03:49 +04:00
for_each_online_cpu ( j ) {
2012-10-26 02:47:42 +04:00
struct od_cpu_dbs_info_s * dbs_info ;
2009-06-24 10:13:48 +04:00
dbs_info = & per_cpu ( od_cpu_dbs_info , j ) ;
2012-10-26 02:47:42 +04:00
dbs_info - > cdbs . prev_cpu_idle = get_cpu_idle_time ( j ,
& dbs_info - > cdbs . prev_cpu_wall ) ;
2013-03-27 19:58:58 +04:00
if ( od_tuners - > ignore_nice )
2012-10-26 02:47:42 +04:00
dbs_info - > cdbs . prev_cpu_nice =
kcpustat_cpu ( j ) . cpustat [ CPUTIME_NICE ] ;
2009-01-23 17:25:02 +03:00
2005-06-01 06:03:47 +04:00
}
return count ;
}
2013-03-27 19:58:58 +04:00
static ssize_t store_powersave_bias ( struct dbs_data * dbs_data , 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 22:28:12 +04:00
{
2013-03-27 19:58:58 +04:00
struct od_dbs_tuners * od_tuners = dbs_data - > tuners ;
[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 22:28:12 +04:00
unsigned int input ;
int ret ;
ret = sscanf ( buf , " %u " , & input ) ;
if ( ret ! = 1 )
return - EINVAL ;
if ( input > 1000 )
input = 1000 ;
2013-03-27 19:58:58 +04:00
od_tuners - > powersave_bias = input ;
[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 22:28:12 +04:00
ondemand_powersave_bias_init ( ) ;
return count ;
}
2013-03-27 19:58:58 +04:00
show_store_one ( od , sampling_rate ) ;
show_store_one ( od , io_is_busy ) ;
show_store_one ( od , up_threshold ) ;
show_store_one ( od , sampling_down_factor ) ;
show_store_one ( od , ignore_nice ) ;
show_store_one ( od , powersave_bias ) ;
declare_show_sampling_rate_min ( od ) ;
gov_sys_pol_attr_rw ( sampling_rate ) ;
gov_sys_pol_attr_rw ( io_is_busy ) ;
gov_sys_pol_attr_rw ( up_threshold ) ;
gov_sys_pol_attr_rw ( sampling_down_factor ) ;
gov_sys_pol_attr_rw ( ignore_nice ) ;
gov_sys_pol_attr_rw ( powersave_bias ) ;
gov_sys_pol_attr_ro ( sampling_rate_min ) ;
static struct attribute * dbs_attributes_gov_sys [ ] = {
& sampling_rate_min_gov_sys . attr ,
& sampling_rate_gov_sys . attr ,
& up_threshold_gov_sys . attr ,
& sampling_down_factor_gov_sys . attr ,
& ignore_nice_gov_sys . attr ,
& powersave_bias_gov_sys . attr ,
& io_is_busy_gov_sys . attr ,
2005-04-17 02:20:36 +04:00
NULL
} ;
2013-03-27 19:58:58 +04:00
static struct attribute_group od_attr_group_gov_sys = {
. attrs = dbs_attributes_gov_sys ,
. name = " ondemand " ,
} ;
static struct attribute * dbs_attributes_gov_pol [ ] = {
& sampling_rate_min_gov_pol . attr ,
& sampling_rate_gov_pol . attr ,
& up_threshold_gov_pol . attr ,
& sampling_down_factor_gov_pol . attr ,
& ignore_nice_gov_pol . attr ,
& powersave_bias_gov_pol . attr ,
& io_is_busy_gov_pol . attr ,
NULL
} ;
static struct attribute_group od_attr_group_gov_pol = {
. attrs = dbs_attributes_gov_pol ,
2005-04-17 02:20:36 +04:00
. name = " ondemand " ,
} ;
/************************** sysfs end ************************/
2013-03-27 19:58:58 +04:00
static int od_init ( struct dbs_data * dbs_data )
{
struct od_dbs_tuners * tuners ;
u64 idle_time ;
int cpu ;
tuners = kzalloc ( sizeof ( struct od_dbs_tuners ) , GFP_KERNEL ) ;
if ( ! tuners ) {
pr_err ( " %s: kzalloc failed \n " , __func__ ) ;
return - ENOMEM ;
}
cpu = get_cpu ( ) ;
idle_time = get_cpu_idle_time_us ( cpu , NULL ) ;
put_cpu ( ) ;
if ( idle_time ! = - 1ULL ) {
/* Idle micro accounting is supported. Use finer thresholds */
tuners - > up_threshold = MICRO_FREQUENCY_UP_THRESHOLD ;
tuners - > adj_up_threshold = MICRO_FREQUENCY_UP_THRESHOLD -
MICRO_FREQUENCY_DOWN_DIFFERENTIAL ;
/*
* In nohz / micro accounting case we set the minimum frequency
* not depending on HZ , but fixed ( very low ) . The deferred
* timer might skip some samples if idle / sleeping as needed .
*/
dbs_data - > min_sampling_rate = MICRO_FREQUENCY_MIN_SAMPLE_RATE ;
} else {
tuners - > up_threshold = DEF_FREQUENCY_UP_THRESHOLD ;
tuners - > adj_up_threshold = DEF_FREQUENCY_UP_THRESHOLD -
DEF_FREQUENCY_DOWN_DIFFERENTIAL ;
/* For correct statistics, we need 10 ticks for each measure */
dbs_data - > min_sampling_rate = MIN_SAMPLING_RATE_RATIO *
jiffies_to_usecs ( 10 ) ;
}
tuners - > sampling_down_factor = DEF_SAMPLING_DOWN_FACTOR ;
tuners - > ignore_nice = 0 ;
tuners - > powersave_bias = 0 ;
tuners - > io_is_busy = should_io_be_busy ( ) ;
dbs_data - > tuners = tuners ;
pr_info ( " %s: tuners %p \n " , __func__ , tuners ) ;
mutex_init ( & dbs_data - > mutex ) ;
return 0 ;
}
static void od_exit ( struct dbs_data * dbs_data )
{
kfree ( dbs_data - > tuners ) ;
}
2012-10-26 02:47:42 +04:00
define_get_cpu_dbs_routines ( od_cpu_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 19:26:06 +04:00
2012-10-26 02:47:42 +04:00
static struct od_ops od_ops = {
. powersave_bias_init_cpu = ondemand_powersave_bias_init_cpu ,
. powersave_bias_target = powersave_bias_target ,
. freq_increase = dbs_freq_increase ,
} ;
2006-06-29 00:51:19 +04:00
2013-03-27 19:58:58 +04:00
static struct common_dbs_data od_dbs_cdata = {
2012-10-26 02:47:42 +04:00
. governor = GOV_ONDEMAND ,
2013-03-27 19:58:58 +04:00
. attr_group_gov_sys = & od_attr_group_gov_sys ,
. attr_group_gov_pol = & od_attr_group_gov_pol ,
2012-10-26 02:47:42 +04:00
. get_cpu_cdbs = get_cpu_cdbs ,
. get_cpu_dbs_info_s = get_cpu_dbs_info_s ,
. gov_dbs_timer = od_dbs_timer ,
. gov_check_cpu = od_check_cpu ,
. gov_ops = & od_ops ,
2013-03-27 19:58:58 +04:00
. init = od_init ,
. exit = od_exit ,
2012-10-26 02:47:42 +04:00
} ;
2005-04-17 02:20:36 +04:00
2012-10-26 02:47:42 +04:00
static int od_cpufreq_governor_dbs ( struct cpufreq_policy * policy ,
unsigned int event )
2005-04-17 02:20:36 +04:00
{
2013-03-27 19:58:58 +04:00
return cpufreq_governor_dbs ( policy , & od_dbs_cdata , event ) ;
2005-04-17 02:20:36 +04:00
}
2012-10-26 02:47:42 +04:00
# ifndef CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
static
2010-05-09 19:26:51 +04:00
# endif
2012-10-26 02:47:42 +04:00
struct cpufreq_governor cpufreq_gov_ondemand = {
. name = " ondemand " ,
. governor = od_cpufreq_governor_dbs ,
. max_transition_latency = TRANSITION_LATENCY_LIMIT ,
. owner = THIS_MODULE ,
} ;
2005-04-17 02:20:36 +04:00
static int __init cpufreq_gov_dbs_init ( void )
{
2011-01-26 14:12:50 +03:00
return cpufreq_register_governor ( & cpufreq_gov_ondemand ) ;
2005-04-17 02:20:36 +04:00
}
static void __exit cpufreq_gov_dbs_exit ( void )
{
2007-10-03 00:28:12 +04:00
cpufreq_unregister_governor ( & cpufreq_gov_ondemand ) ;
2005-04-17 02:20:36 +04:00
}
2006-06-29 00:52:18 +04: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-18 09:43:44 +03:00
" Low Latency Frequency Transition capable processors " ) ;
2006-06-29 00:52:18 +04:00
MODULE_LICENSE ( " GPL " ) ;
2005-04-17 02:20:36 +04:00
2008-01-18 02:21:08 +03:00
# ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
fs_initcall ( cpufreq_gov_dbs_init ) ;
# else
2005-04-17 02:20:36 +04:00
module_init ( cpufreq_gov_dbs_init ) ;
2008-01-18 02:21:08 +03:00
# endif
2005-04-17 02:20:36 +04:00
module_exit ( cpufreq_gov_dbs_exit ) ;