There seems to be a major difference in the behavior of the ondemand governor depending on whether CONFIG_NO_HZ is set or not in the kernel .config. In the NO_HZ case the ondemand governor spends too much time at the highest frequency and is also very trigger happy. I have compared the two cases on my system: powernow-k8: Found 1 AMD Phenom(tm) II X4 955 Processor (4 cpu cores) (version 2.20.00) powernow-k8: 0 : pstate 0 (3200 MHz) powernow-k8: 1 : pstate 1 (2500 MHz) powernow-k8: 2 : pstate 2 (2100 MHz) powernow-k8: 3 : pstate 3 (800 MHz) When I run: watch -n.1 'cat /proc/cpuinfo|grep MHz' on an otherwise idle system, I can see that the frequency always stays at 800 MHz in the "CONFIG_NO_HZ not set" case. But it will very frequently switch to 3200 MHz in the CONFIG_NO_HZ=y case under the same conditions. This also manifests itself in the cpufreq/stats/time_in_state statistics (again on a mostly idle system): First taken with: echo 200 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor (BTW wouldn't it make sense to use something like this as the default value?) cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state CONFIG_NO_HZ not set: 3200000 5845 2500000 0 2100000 5 800000 31552 CONFIG_NO_HZ=y: 3200000 17650 2500000 0 2100000 0 800000 31129 And with the default sampling_down_factor=1 CONFIG_NO_HZ not set: 3200000 140 2500000 2 2100000 29 800000 16614 CONFIG_NO_HZ=y: 3200000 538 2500000 9 2100000 77 800000 16287 Now my question is, is this expected? And what could be done to make the NO_HZ behavior more like the "CONFIG_NO_HZ not set" behavior. -- Markus -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
