diff options
author | Alexander Clouter <alex@digriz.org.uk> | 2006-03-22 09:54:10 +0000 |
---|---|---|
committer | Dominik Brodowski <linux@dominikbrodowski.net> | 2006-03-26 10:13:05 +0200 |
commit | 2c906b317b2d9c7e32b0d513e102bd68a2c49112 (patch) | |
tree | dcb86235f25d11e8662d75a9b185a7098cf17fd5 /drivers/usb/storage | |
parent | 36ddf5bbdea7ba4582abc62f106f0f0e9f0b6b91 (diff) | |
download | linux-2c906b317b2d9c7e32b0d513e102bd68a2c49112.tar.bz2 |
[PATCH] cpufreq_conservative: aligning of codebase with ondemand
Since the conservative govenor was released its codebase has drifted from the
the direction and updates that have been applied to the ondemand govornor.
This patch addresses the lack of updates in that period and brings
conservative back up to date. The resulting diff file between
cpufreq_ondemand.c and cpufreq_conservative.c is now much smaller and shows
more clearly the differences between the two.
Another reason to do this is ages ago, knowingly, I did a piss poor attempt
at making conservative less responsive by knocking up
DEF_SAMPLING_RATE_LATENCY_MULTIPLIER by two orders of magnitude. I did fix
this ages ago but in my dis-organisation I must have toasted the diff and
left it the way it was. About two weeks ago a user contacted me saying he
was having problems with the conservative governor with his AMD Athlon XP-M
2800+ as /sys/devices/system/cpu/cpu0/cpufreq/conservative showed
sampling_rate_min 9950000
sampling_rate_max 1360065408
Nine seconds to decide about changing the frequency....not too responsive :)
Signed-off-by: Alexander Clouter <alex-kernel@digriz.org.uk>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Diffstat (limited to 'drivers/usb/storage')
0 files changed, 0 insertions, 0 deletions