*NEW* patches, for kernel 2.6.16
Something I had been meaning to do for a while. The codebases between
ondemand and conservative have strayed and as Venkatesh has far more Clue(tm)
than I am going to adjust my code to look more like his :)
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 <[email protected]>
Alexander Clouter <[email protected]> wrote:
>
> *NEW* patches, for kernel 2.6.16
>
> Something I had been meaning to do for a while. The codebases between
> ondemand and conservative have strayed and as Venkatesh has far more Clue(tm)
> than I am going to adjust my code to look more like his :)
>
> 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 :)
umm, that's not really a changelog. Please, see
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt. Section 2a is
relevant too..
Thanks.