Bug#421879: cpufreq_ondemand: cpufreq_ondemand responds too slowly
this is the p4_clockmod code:
policy->cpuinfo.transition_latency = 1000000; /* assumed */
it's expressed in nS so it's 1mS.
And by the way this is a comment in cpufreq_ondemand.c that may
enlighten some more:
/*
* The polling frequency of this governor depends on the capability of
* the processor. Default polling frequency is 1000 times the transition
* latency of the processor. The governor will work on any processor with
* transition latency <= 10mS, using appropriate sampling
* rate.
* For CPUs with transition latency > 10mS (mostly drivers with CPUFREQ_ETERNAL)
* this governor will not work.
* All times here are in uS.
*/
OK. So, if I can find an actual specification for the transition
latency, you could replace the assumed value with the real one.
Right?
I'd also suggest changing (in cpufreq_ondemand.c )
#define MIN_SAMPLING_RATE (def_sampling_rate / 2)
to
#define MIN_SAMPLING_RATE (def_sampling_rate / 10)
The current MIN_SAMPLING_RATE enforces a fairly conservative,
slow sampling rate. By lowering the limit, you could allow people to
experiment and tune their systems, and see if a more rapid sampling
rate would actually improve things or not.
(Note that this would not change the default behavior at all!)
Even with this more agressive limit, the CPU would still (at worst)
only be spending 1% of its time in the middle of a transition between
one speed and another. It's easy to imagine that some people would
trade off a 1% overhead for more rapid response to a mouse motion.
Anyhow, there are good human interface reasons to try to get the
sampling rate down to 100ms, if it can be done without affecting
overall performance significantly. Reducing the MIN_SAMPLING_RATE
allows people to experiment easily, so it ought to be a good idea.
Reply to: