summaryrefslogtreecommitdiff
path: root/lib/mpi/mpicoder.c
diff options
context:
space:
mode:
authorRamakrishna Gottimukkula <rgottimu@codeaurora.org>2017-07-26 23:33:28 +0530
committerRamakrishna Gottimukkula <rgottimu@codeaurora.org>2017-07-28 16:02:47 +0530
commit168e1040e746ae88623a2171af0decaad69358f5 (patch)
tree2f23e31a5e5b2c174acd13b94ce5b0427bf9b2fb /lib/mpi/mpicoder.c
parentac8211566ba58dd2be22c399f559a44a09054bf4 (diff)
cpufreq: interactive: fix to come out of hysteresis mode
If policy max is set to less than or equal to hispeed_freq, governor can get stuck in hysteresis mode as long as cpufreq_interactive_timer keeps coming with in hysteresis period (max_freq_hysteresis). This is because governor updates hysteresis start time (max_freq_hyst_start_time) everytime new frequency is greater than or equal to policy max and jump_to_max_no_ts flag is false. Irrespective of load new frequency in this case will always end up at least at hispeed_freq due to hysteresis. As policy max is set to less than or equal to hispeed_freq, this will result in updating max_freq_hyst_start_time if jump_to_max_no_ts is false. This will end up restarting hysteresis period. This mode will break only if timer gets delivered after hysteresis period. Otherwise it keeps extending. To come out of this, don't update max_freq_hyst_start_time if new frequency is bumped up to hispeed_freq due to hysteresis even though the required frequency as per load is less than policy max and hispeed_freq. Change-Id: Ib1e9e612036afeb12acd86e603b019e227920d85 Signed-off-by: Ramakrishna Gottimukkula <rgottimu@codeaurora.org>
Diffstat (limited to 'lib/mpi/mpicoder.c')
0 files changed, 0 insertions, 0 deletions