Ondemand governor not working with kernel-2.6.12-12mdk
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hello Eric,
Quoted 3 lines
Quoted 1 line
Here it is. It's against 2.6.13 but should
apply cleanly against 2.6.12.
Your patch did the trick, thanks! The only draw back is that the responsiveness is not
so good - it takes at least 2-3 seconds to switch to the highest frequency and back, when thie high load is over. Is it supposed to be like that by design, or this latency could be changed?
Quoted 3 lines
If it works (or doesn't), could you also
email the cpufreq list, to
continue the thread there?
Sorry, I forgot to CC it to the cpufreq list. Here it is now.
Alex
Quoted 7 lines
Eric
Quoted 1 line
---
linux-2.6.13/arch/i386/kernel/cpu/cpufreq/speedstep-ich.c.bak
2005-08-08 10:14:35.000000000 +0200+++
linux-2.6.13/arch/i386/kernel/cpu/cpufreq/speedstep-ich.c
Quoted 56 lines
2005-09-17 12:50:27.000000000 +0200(quoted diff) +0
-0@@ -301,6 +301,35 @@ static int
speedstep_verify(struct cpuf
}+/**
+ *speedstep_get_transition_latency- returns
the maximum transition latency
+ * of the current processor
+ * @processor: type of processor
+ *
+ * The CPU transition latency depends on the
type of CPU, so we get it
+ * from a database.
+ */
+static unsigned int
speedstep_get_transition_latency(unsigned int
processor)(quoted diff) +5
-0+{ + switch (processor) { + case SPEEDSTEP_PROCESSOR_PIII_C: + case SPEEDSTEP_PROCESSOR_PIII_C_EARLY: + /* According to intel's p3_ds.pdf p.23 andtable 22, similar to
PIII_T*/(quoted diff) +2
-0+ case SPEEDSTEP_PROCESSOR_PIII_T: + /* Max 100µs, according to intel's29834006.pdf p.22 */
(quoted diff) +4
-0+ return 100000; + case SPEEDSTEP_PROCESSOR_P4M: + /* + * Depends on the bus clock, which should beat least 100MHz.
(quoted diff) +1
-0+ * Max ~42µs -> 50µs, according to intel's25068607.pdf p.40 and p.50
(quoted diff) +4
-0+ */ + return 50000; + default: + /* No info has yet be found, so we areconservative */
(quoted diff) +4
-0+ return CPUFREQ_ETERNAL; + } +} + static int speedstep_cpu_init(struct
cpufreq_policy*policy)
{(quoted diff) +0
-0int result = 0;@@ -335,7 +364,8 @@ static intspeedstep_cpu_init(struct cpu
(quoted diff) +0
-1/* cpuinfo and default policy values */ policy->governor = CPUFREQ_DEFAULT_GOVERNOR; - policy->cpuinfo.transition_latency =
CPUFREQ_ETERNAL;
Review
Quoted 2 lines
(quoted diff) +2
-0+ policy->cpuinfo.transition_latency = +
speedstep_get_transition_latency(speedstep_processor);
Quoted 6 lines
(quoted diff) +0
-0policy->cur = speed; result =cpufreq_frequency_table_cpuinfo(policy,
speedstep_freqs);
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
Quoted 1 line · Alex Simonov wrote/
Hello Eric,
:
Quoted 7 lines
Your patch did the trick, thanks! The only draw
back is that the responsiveness is not so good - it takes at least 2-3 seconds to switch to the highest frequency and back, when thie high load is over. Is it supposed to be like
that by design, or this latency could be changed?
That's strange, it's supposed to be faster (although it could be even faster). IIRC, on 2.6.12, it should be every 100 milliseconds. You can check the sampling frequency of the ondemand governor by doing a cat /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate
It will give the period between each frequency update in microseconds. In general, it should change from low to high in a tenth of a second. You can check it with a stupid shell command like this (when nothing else is running), this is only one line:
# date +%T.%N; while test $(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq) != $(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq) ; do true ; done ; date +%T.%N
By doing the difference between the two times displayed you'll know how long it takes for the ondemand governor to change to the high frequency.
Here (pentium III), it takes about 0.08s .
Eric