summaryrefslogtreecommitdiffstats
path: root/drivers/usb/storage
diff options
context:
space:
mode:
authorAlexander Clouter <alex@digriz.org.uk>2006-03-22 09:54:10 +0000
committerDominik Brodowski <linux@dominikbrodowski.net>2006-03-26 10:13:05 +0200
commit2c906b317b2d9c7e32b0d513e102bd68a2c49112 (patch)
treedcb86235f25d11e8662d75a9b185a7098cf17fd5 /drivers/usb/storage
parent36ddf5bbdea7ba4582abc62f106f0f0e9f0b6b91 (diff)
downloadlinux-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