On Friday 13 February 2009 08:03:26 pm Alexander Clouter wrote:
> AMD users get particular hit by this issue (bug 8081) as it caps at
> typically 90 seconds as the minimum period for a frequency change.
> Harsh eh? Years ago I borked this buy puting the 10x in the wrong
> place...I fix that by removing it altogether.
>
> Signed-off-by: Alexander Clouter <alex@xxxxxxxxxxxxx>
> ---
> drivers/cpufreq/cpufreq_conservative.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq_conservative.c
> b/drivers/cpufreq/cpufreq_conservative.c index c9bd0c5..2ecd95e 100644
> --- a/drivers/cpufreq/cpufreq_conservative.c
> +++ b/drivers/cpufreq/cpufreq_conservative.c
> @@ -599,7 +599,7 @@ static int cpufreq_governor_dbs(struct cpufreq_policy
> *policy, latency = 1;
>
> def_sampling_rate =
> - max(10 * latency * LATENCY_MULTIPLIER,
> + max(latency * LATENCY_MULTIPLIER,
This is a good idea. First I thought it is intended to poll that seldom to
save power compared to ondemand.
Thinking about it again, you get extremely high sampling frequencies with
that (AFAIK about 0.5 - 1.1s on Pentium M and K8 CPUs). Thus the conservative
governor probably showed really bad performance values before when only
checking for CPU load every second.
Signed-off-by: Thomas Renninger <trenn@xxxxxxx>
Thomas
--
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
