Running a kernel that never enables the interactive cpufreq
will eventually hit the following warning:
INFO: task kinteractiveup:112 blocked for more than 120 seconds.
kinteractiveup D c07ae3a4 7072 112 2 0x00000000
[<c07ae3a4>] (__schedule+0x4e4/0x5c4) from [<c00a1b8c>] (kthread+0x70/0x94)
[<c00a1b8c>] (kthread+0x70/0x94) from [<c000f368>]
(kernel_thread_exit+0x0/0x8)
due to the fact that the kthread is never woken up after being
forked. Kick the thread to its idle loop so that it can
schedule() and move out of the D state.
Change-Id: Idc490e707d9a14dd143306a8ee1c2241320d29d5
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
When a new cpu is added and if does not enter idle
for long, the interactive timer is not started and hence
the cpu remains at lowest frequecny, despite the system
load. This impacts mainly benchmarks. Starting a timer
at governor start to handle low frequency.
Change-Id: I8ac9705b9f166a95715c985efacd2ae8ef387cb7
Signed-off-by: Narayanan Gopalakrishnan <nargop@codeaurora.org>
Allow speed to drop to flooor frequency but not below, don't pin
to speed at last boost.
Change-Id: I0147c2b7a2e61ba16820605af6baaf09570be787
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Based on previous patches by Tero Kristo <tero.kristo@nokia.com>,
Brian Steuer <bsteuer@codeaurora.org>,
David Ng <dave@codeaurora.org>,
Antti P Miettinen <amiettinen@nvidia.com>, and
Thomas Renninger <trenn@suse.de>
Change-Id: Ic55fedcf6f9310f43a7022fb88e23b0392122769
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Allow speed drop after min_sample_time elapses from last time
the current speed was last re-validated as appropriate for
current load / input boost.
Allow speed bump after min_sample_time (or above_hispeed_delay)
elapses from the time the current speed was originally set.
Change-Id: Ic25687a7a53d25e6544c30c47d7ab6f27a47bee8
Signed-off-by: Todd Poynor <toddpoynor@google.com>
For systems that set a common speed for all CPUs, checking current
speed here could bypass the intermediate hispeed bump decision for
this CPU when another CPU was already at hispeed. This could
result in an overly high setting (for all CPUs) in situations
where all CPUs were about to drop to load levels that map to
hispeed or below.
Change-Id: I186f23dcfc5e2b6336cab8b0327f0c8a9a4482bc
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Apply min_sample_time to the last time the current target speed
was originally requested or re-validated as appropriate for the
current load, not to the time since the current speed was
originally set. Avoids periodic dips in speed during bursty
loads.
Change-Id: I250bda657985de60373f9897cc41f480664d51a1
Signed-off-by: Todd Poynor <toddpoynor@google.com>
If load is above go_hispeed_load, always go to at least hispeed_freq,
even when reducing speed from a higher speed, not just when jumping
up from minimum speed. Avoids running at a lower than intended
speed after a burst of even higher load.
Change-Id: I5b9d2a15ba25ce609b21bac7c724265cf6838dee
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Evaluate spikes in load (below go_hispeed_load) against the maximum
speed supported by the device, not the current speed (which tends to
make it too difficult to raise speed to intermediate levels until
very busy).
Change-Id: Ib937006abf8bedb60891a739acd733e89b732ae0
Signed-off-by: Todd Poynor <toddpoynor@google.com>
This governor is designed for latency-sensitive workloads, such as
interactive user interfaces. The interactive governor aims to be
significantly more responsive to ramp CPU quickly up when CPU-intensive
activity begins.
Existing governors sample CPU load at a particular rate, typically
every X ms. This can lead to under-powering UI threads for the period of
time during which the user begins interacting with a previously-idle system
until the next sample period happens.
The 'interactive' governor uses a different approach. Instead of sampling
the CPU at a specified rate, the governor will check whether to scale the
CPU frequency up soon after coming out of idle. When the CPU comes out of
idle, a timer is configured to fire within 1-2 ticks. If the CPU is very
busy from exiting idle to when the timer fires then we assume the CPU is
underpowered and ramp to MAX speed.
If the CPU was not sufficiently busy to immediately ramp to MAX speed, then
the governor evaluates the CPU load since the last speed adjustment,
choosing the highest value between that longer-term load or the short-term
load since idle exit to determine the CPU speed to ramp to.
A realtime thread is used for scaling up, giving the remaining tasks the
CPU performance benefit, unlike existing governors which are more likely to
schedule rampup work to occur after your performance starved tasks have
completed.
The tuneables for this governor are:
/sys/devices/system/cpu/cpufreq/interactive/min_sample_time:
The minimum amount of time to spend at the current frequency before
ramping down. This is to ensure that the governor has seen enough
historic CPU load data to determine the appropriate workload.
Default is 80000 uS.
/sys/devices/system/cpu/cpufreq/interactive/go_maxspeed_load
The CPU load at which to ramp to max speed. Default is 85.
Change-Id: Ib2b362607c62f7c56d35f44a9ef3280f98c17585
Signed-off-by: Mike Chan <mike@android.com>
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Bug: 3152864
