summaryrefslogtreecommitdiffstats
path: root/drivers/cpufreq/freq_table.c
diff options
context:
space:
mode:
authorMyungJoo Ham <myungjoo.ham@samsung.com>2012-02-29 17:54:41 +0900
committerDave Jones <davej@redhat.com>2012-02-29 22:24:40 -0500
commitfd0ef7a0583b9af3efeb7b1f965ea80b5ff70cdf (patch)
tree3ed8deaecc23fd71d5c777c962c9833f071bc7e7 /drivers/cpufreq/freq_table.c
parent34ee55075265d68ca858f2426e165733664385b4 (diff)
[CPUFREQ] CPUfreq ondemand: update sampling rate without waiting for next sampling
When a new sampling rate is shorter than the current one, (e.g., 1 sec --> 10 ms) regardless how short the new one is, the current ondemand mechanism wait for the previously set timer to be expired. For example, if the user has just expressed that the sampling rate should be 10 ms from now and the previous was 1000 ms, the new rate may become effective 999 ms later, which could be not acceptable for the user if the user has intended to speed up sampling because the system is expected to react to CPU load fluctuation quickly from __now__. In order to address this issue, we need to cancel the previously set timer (schedule_delayed_work) and reset the timer if resetting timer is expected to trigger the delayed_work ealier. Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
Diffstat (limited to 'drivers/cpufreq/freq_table.c')
0 files changed, 0 insertions, 0 deletions