Since October last year the kernel (>=2.6.37) has a new tunable for the
ondemand CPUfreq governor called sampling_down_factor.

Quote from Documentation/cpu-freq/governors.txt:

Quote:

sampling_down_factor: this parameter controls the rate at which the
kernel makes a decision on when to decrease the frequency while running
at top speed. When set to 1 (the default) decisions to reevaluate load
are made at the same interval regardless of current clock speed. But
when set to greater than 1 (e.g. 100) it acts as a multiplier for the
scheduling interval for reevaluating load when the CPU is at its top
speed due to high load. This improves performance by reducing the overhead
of load evaluation and helping the CPU stay at its top speed when truly
busy, rather than shifting back and forth in speed. This tunable has no
effect on behavior at lower speeds/lower CPU loads.

a more elegant solution, then just add cpufrequtils to your runtime via rc-update_________________The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king

I tried this for a while now and -- for me at least -- there is a big
downside.

HD video plays extremely "choppy" with sound break-ups.

I'm not sure why this is happening, but when sampling_down_factor is
reset to 1, my videos play smooth.

(note this is on a notebook with 1.2ghz core 2 duo that downclocks to
800 mhz)_________________.... there is nothing - absolutely nothing - half so much worth
doing as simply messing about with Linux ...
(apologies to Kenneth Graeme)

I tried this for a while now and -- for me at least -- there is a big
downside.

HD video plays extremely "choppy" with sound break-ups.

I'm not sure why this is happening, but when sampling_down_factor is
reset to 1, my videos play smooth.

(note this is on a notebook with 1.2ghz core 2 duo that downclocks to
800 mhz)

What kernel version are you running?
Because there was an important bug-fix in 2.6.39. Before the fix
the CPU frequency could accidentally be stuck at a low frequency
for a long time (depending on the sampling_down_factor).
(see commit 5cb2c3bd in the kernel git tree.)
That could explain your symptoms.

Hey, thanks trippels for this thread! I was having quite an issue recently with my desktop cpu being stucked at the lowest p-state while my laptop was stucked on the highest. I had and still have powersave as the default governor--I'll go for ondemand next time I build my kernels. With this trick and ondemand governor my issue vanish. I was looking for a solution only to find nothing. And anyway, I use kernel--2.6.3{8{-pf8,.8-zen},9-pf3}--with zcache (and cleancache) pach for .38*. I started, at first, suspecting zcache patch but it wasn't the culpirit. The weird thing is 38-pf8 without zcache worked great a few weeks before, the same goes for .39-pf*. As there were a few issues with BFS and such in .39, I decided to stick with .38! Actually, I have a few power profiles with hprofile but I did not bother until now to put a power profile in the init service. Now it's done! I won't bother changing it with on demand governor or change my powersave profile with ondemand governor.