tree 9607e924f228de590fcbc2b8be53391385debea2
parent e627d70739c085535d61da21bc31b70be4411285
author Junjie Wu <junjiew@codeaurora.org> 1427317549 -0700
committer Stephen Boyd <sboyd@codeaurora.org> 1490037371 -0700

cpufreq: interactive: Ramp up directly if cpu_load exceeds 100

When governor is using regular busy time tracking, cpu_load will
never exceed 100 because busy time will never exceed elapsed time in
any one sampling window. The only exception is when frequency is
reduced in middle of a window (e.g. due to thermal throttling). In
this case, cpu_load is likely irrelevant since current frequency
governor has been voting is already higher than what target can run
at.

However, on a heterogeneous CPU system with scheduler input enabled
to track the load of migrated tasks, cpu_load could also exceed 100
when a task migrates from more capable CPU to slower CPU. When this
happens, governor already knows the exact frequency required to handle
this load. There is no need to progressively ramp up frequency in order
to assess the load's real demand. It's not desirable to starve such a
migrating task by forcing it through ramping up process on the slower
CPU.

Direclty jump beyond hispeed_freq and ignore above_hispeed_delay if
cpu_load exceeds 100.

Change-Id: Ib87057e4f00732fad943ab595a33e3059494ef15
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>