diff options
author | Thomas Renninger <trenn@suse.de> | 2009-04-22 13:48:29 +0200 |
---|---|---|
committer | Dave Jones <davej@redhat.com> | 2009-06-15 11:49:41 -0400 |
commit | cef9615a853ebc4972084f7e70b52892557420ac (patch) | |
tree | 9578c3371f57ab16be61e18aec307b450106106b /arch/x86/kernel/cpu/cpufreq/powernow-k8.c | |
parent | 45e3e1935e2857c54783291107d33323b3ef33c8 (diff) | |
download | linux-stable-cef9615a853ebc4972084f7e70b52892557420ac.tar.gz linux-stable-cef9615a853ebc4972084f7e70b52892557420ac.tar.bz2 linux-stable-cef9615a853ebc4972084f7e70b52892557420ac.zip |
[CPUFREQ] ondemand: Uncouple minimal sampling rate from HZ in NO_HZ case
With this patch you have following minimal sampling rate restrictions:
Kernel restrictions:
If CONFIG_NO_HZ is set, the limit is 10ms fixed.
If CONFIG_NO_HZ is not set or no_hz=off boot parameter is used, the
limits depend on the CONFIG_HZ option:
HZ=1000: min=20000us (20ms)
HZ=250: min=80000us (80ms)
HZ=100: min=200000us (200ms)
HW restrictions:
Do not sample/poll more often than HW latency * 100 exported by the low
level cpufreq HW driver
The higher value of above restrictions is the minimal sampling rate
that can be set (and can be seen via ondemand/sampling_rate_min sysfs file)
Default sampling rate still is HW latency * 1000, but this will now end
up in lower values on latest (Intel and AMD) hardware as these can switch
really fast and sampling rate mostly was limited to the 80ms or 200ms
(depending on whether HZ=250 or HZ=1000 is used).
Signed-off-by: Thomas Renninger <trenn@suse.de>
Cc: Pallipadi Venkatesh <venkatesh.pallipadi@intel.com>
Signed-off-by: Dave Jones <davej@redhat.com>
Diffstat (limited to 'arch/x86/kernel/cpu/cpufreq/powernow-k8.c')
0 files changed, 0 insertions, 0 deletions