summaryrefslogtreecommitdiff
path: root/drivers/cpufreq/imx6q-cpufreq.c
diff options
context:
space:
mode:
authorChen Yu <yu.c.chen@intel.com>2018-06-08 04:07:33 +0300
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2018-06-08 12:40:44 +0300
commit7592019634f8473f0b0973ce79297183077bdbc2 (patch)
treeca24a1ed9dff3c4eb4e70e27e382aaf51163eb3f /drivers/cpufreq/imx6q-cpufreq.c
parent41ab43c9c89e06ff08a4750d1b09e227ea97894f (diff)
downloadlinux-7592019634f8473f0b0973ce79297183077bdbc2.tar.xz
cpufreq: governors: Fix long idle detection logic in load calculation
According to current code implementation, detecting the long idle period is done by checking if the interval between two adjacent utilization update handlers is long enough. Although this mechanism can detect if the idle period is long enough (no utilization hooks invoked during idle period), it might not cover a corner case: if the task has occupied the CPU for too long which causes no context switches during that period, then no utilization handler will be launched until this high prio task is scheduled out. As a result, the idle_periods field might be calculated incorrectly because it regards the 100% load as 0% and makes the conservative governor who uses this field confusing. Change the detection to compare the idle_time with sampling_rate directly. Reported-by: Artem S. Tashkinov <t.artem@mailcity.com> Signed-off-by: Chen Yu <yu.c.chen@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Diffstat (limited to 'drivers/cpufreq/imx6q-cpufreq.c')
0 files changed, 0 insertions, 0 deletions