diff options
| author | Junjie Wu <junjiew@codeaurora.org> | 2015-06-09 17:36:11 -0700 |
|---|---|---|
| committer | David Keitel <dkeitel@codeaurora.org> | 2016-03-23 21:25:29 -0700 |
| commit | 3eb23fd73cdde9176d3c5e8d6a39c7eacb446436 (patch) | |
| tree | a4d2b043c0db237e56c48bd6ceec6b9e0434679e /Documentation/cpu-freq | |
| parent | 1a76fe2389d173d6bbe4fd12e078205fe0095a4c (diff) | |
cpufreq: interactive: Use load prediction provided by scheduler
With modification in scheduler, governor now gets predicted
instantaneous demand waiting to run in addition to demand from
previous window for each CPU. Make use of this information since
prediction from scheduler could be more accurate than just looking at
past few windows.
Governor calculates two frequencies during each sampling period: one based
on demand in previous sampling period (f_prev), and the other based on
prediction provided by scheduler (f_pred). Max of both will be selected
as final frequency. Hispeed related logic, including both frequency
selection and delay is ignored when prediction is enabled. If only
f_pred but not f_prev picked policy->max, max_freq_hysteresis period is
not started/extended. This is to reduce power cost of mis-prediction
if it happens.
One use case prediction could dramatically help is when a heavy task
wakes up after sleeping for a long time. With prediction, governor
could ramp up to frequency the task needs much faster than before.
To enable prediction, echo 1 to enable_prediction file in
cpufreq interactive sysfs directory.
Change-Id: I27396785886e43ea01c9000c651c8bd142172273
Suggested-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
Diffstat (limited to 'Documentation/cpu-freq')
| -rw-r--r-- | Documentation/cpu-freq/governors.txt | 10 |
1 files changed, 10 insertions, 0 deletions
diff --git a/Documentation/cpu-freq/governors.txt b/Documentation/cpu-freq/governors.txt index 9a92412d44a1..472122fda585 100644 --- a/Documentation/cpu-freq/governors.txt +++ b/Documentation/cpu-freq/governors.txt @@ -337,6 +337,16 @@ evaluation triggered by timer, min_sample_time is still always enforced. fast_ramp_down has no effect if use_migration_notif is set to zero. Default is zero. +enable_prediction: If non-zero, two frequencies will be calculated +during each sampling period: one based on busy time in previous sampling +period (f_prev), and the other based on prediction provided by scheduler +(f_pred). Max of both will be selected as final frequency. Hispeed +related logic, including both frequency selection and delay is ignored +if enable_prediction is set. If only f_pred but not f_prev picked +policy->max, max_freq_hysteresis period is not started/extended. +use_sched_load must be turned on before enabling this feature. +Default is zero. + 3. The Governor Interface in the CPUfreq Core ============================================= |