switching to top frequency too frequent with ondemand governor and no_hz

[Markus Trippelsdorf <markus@trippelsdorf.de>]

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